There’s a scene in the movie “Parenthood” where two people are imagining being on a roller coaster: one is gripping the safety bar with fear, and the other has their arms up in full enjoyment. I think the journey we’re on transforming software engineering can feel like that, both exhilarating and somewhat terrifying at the same time. The productivity is definitely exhilarating, with more creativity and innovation coming from more people every day. On the other hand, the rate of change is incredibly intense, and I think we all wonder about the future for builders: where is our profession headed?
At Madrona’s 2026 IA40 Summit, I explored this with leaders at the forefront of this transformation: Factory co-founder and CTO Eno Reyes, Atlassian CTO of AI and Teamwork Taroon Mandhana, and Entire co-founder and CEO Thomas Dohmke, previously CEO of GitHub. An ideal combination of leaders who represent where we’ve been and where we’re going.
We covered a lot of ground, from how teams are adjusting to the transformation and gaining confidence in agent autonomy, to the role of context in improving outcomes and efficiency. We also explored what these changes mean for engineering organizations and the role of the builder.
Building Toward Autonomy
Autonomy feels like the next frontier for productivity and throughput. Coding agents have become more capable, but developers are still reluctant to grant them full autonomy. Do we trust the code they produce? Do we trust that it has been adequately verified? And autonomy for what: a prototype, a bug fix, or something more complex?
Taroon described autonomy as a continuum, where you can either automate predictable loops or parts of a loop. At Atlassian, for example, their vulnerability management process is fully automated, triggering a workflow that takes the issue through to a pull request, with people stepping in when the agent needs help. Creating a new product or feature is a different matter and is not fully autonomous today.
Eno sees the opportunity to move beyond the current model of a person assigning an agent a task and waiting for the result. Over time, agents could recognize work that needs to be done in service of a goal and act proactively, with human knowledge and consent, but without needing a person to initiate every task.
That brought us to validation. If agents can produce code continuously, how do we review and validate their work without creating an even bigger bottleneck?
Thomas sees a need for a quality-control layer alongside the layer that builds the code, with agents playing a role in both. Eno drew on Six Sigma, where manufacturers set an acceptable defect rate and build their process around hitting it. Define and track that bar for AI-generated code, and it becomes the basis for deciding when more autonomy is warranted.
We are likely to advance at different speeds for different kinds of work. The more confidence we have in how we validate the code, the more autonomy we will grant these systems.
Better Context, Better Outcomes
Coding agents are generating more code, faster than ever, but that doesn’t necessarily translate into the same improvement in overall engineering throughput. One important part of the answer is giving agents better context.
Taroon described the challenge of bringing together information from across the organization. The context an agent needs might be in code and pull requests, but it might also be in Jira, Confluence, Slack, documents or other systems. Taroon calls Atlassian’s effort to pull this together the Teamwork Graph, its underlying context graph. Atlassian found that adding a graph of service dependencies to its context made its root-cause-analysis agent better.
Having access to information is only part of the challenge. An agent also needs to find the right information for the task at hand. Taroon described this as a retrieval and ranking problem. For example, when reviewing a piece of code, the agent should be able to find relevant context from the engineer who is an authority on that part of the system. He also talked about learning from the work agents do. Atlassian has added agent sessions and transcripts to its context so that lessons from those sessions, including corrections from people, can be used in future work.
Thomas focused on preserving the context that leads to the code. Entire stores the agent’s session alongside the code in Git: what the person asked, what information the agent retrieved and how the work evolved. That gives a future reviewer a way to understand how a change came about, rather than having to reconstruct it from a pull request and the code alone. He described the session and the code together as a new system of record for software development. He also sees evaluations becoming a more important part of review: a change might be merged, sent back to an agent for another iteration, or brought to a person for approval. He likened it to a self-driving car: there’s still a hood you can open and a steering wheel, even if most of the time nobody touches it.
Taroon’s focus was on getting the right context into the work. Thomas’s was on preserving the context that comes out of it. Both are important as we look to improve the quality of the work agents do and the confidence we have in the results.
The Builder’s Role
With all of these changes, I think we’re all wondering what this means for the people who build software. What will the role of a great engineer look like a year or two from now? What will they actually spend their time doing?
Eno sees engineers taking on more responsibility for designing and improving the process that produces software. He used the analogy of a semiconductor process engineer: understand the yield, identify where the process can improve, make a change and measure the result. That engineering-like work, he said, extends across the pipeline, from turning incoming signals into plans to building software and incorporating feedback. He compared it to Excel, which started as a specialist tool and grew into something a billion people use: he expects software building to follow a similar path, with many future builders never looking at the code itself. As he put it, “Everybody starts to look a little bit more like an engineer along this pipeline.”
Taroon described the importance of product-minded generalists who can understand the whole system and optimize for outcomes, not just individual features. At Atlassian, these are skills often associated with staff-level engineers. Increasingly, he wants to see them across the engineering team.
Thomas emphasized creativity and business judgment. Even with more automation, he pointed out, teams’ backlogs aren’t empty. There is still no shortage of ideas, but the work also needs to create value for the business. As he put it, “I can burn all the tokens in the world and increase my revenue by zero.”
The role of the builder is changing, but the need for people who can exercise judgment, understand what to build and create value remains as important as ever.
Looking forward
I believe this is the most important and transformational moment in the history of software. We will give agents more autonomy, and we will improve validation and the systems around them so we can move faster with confidence. We will also address more of the full software lifecycle. Systems that capture and understand the context of the work will be key to that opportunity.
I believe productivity will reach new heights. The role of the builder will continue to evolve, and we will be able to do more with our ideas than ever before. Builders will continue to have the best jobs around.
The pace of change is simply breathtaking, and I look forward to continuing the conversation.
For more on these topics, see my earlier post and the Builders Summit survey results, and watch all our 2026 IA40 sessions here.
Related Insights
