AI, software, ownership and accountability

Bear with me, this post is fairly philosophical and adventurous.

At some point in 2025, software development as an industry was disrupted. Not gradually, and not in the way we anticipated.

How we got here

For decades, we built software the same way. We copied what worked for others and hoped it would work for us.

We split teams by domain. Each discipline (frontend, backend, infrastructure, etc.) carved out its own territory. This made sense because individuals naturally gravitate toward expertise in specific skillsets rather than being generalists. And as codebases grew larger, domain segregation became an easy way to partition knowledge and responsibility. The key factors were always the same: how much context can one person hold, and how broad can their knowledge be while remaining effective.

We created product managers for engineers who didn't want to talk to customers, for those who lacked a product mindset, and because it was yet another specialization we could segregate. We imported project managers from construction because we needed someone to blame when things ran late.

On a different axis, we stacked roles into hierarchies based on years of experience and scope of impact to justify pay, progression and power.

As time went on, we moved from waterfall to agile to scrum, always looking for the next framework that would finally make everything click.

None of it was objectively correct. But it was good enough. If you copied the patterns, hired the right titles, and followed the ceremonies, you had a decent shot at (maybe) shipping software. We all agreed this was the way, even though none of us loved it. We just didn't have a better option.

The objective was clear: a cost optimization problem, where the impact of making a mistake compounds as it moves through the pipeline. We didn't want to plan things we didn't need, nor design things we hadn't planned, nor code things we hadn't designed, and so on.

At its core, we built all of this around two constraints: humans can't hold infinite context, and humans have different interests that lead them to develop specific skillsets. As a result, iteration became expensive because every change had to travel through the human chain we created. This is, in my opinion, one of the main reasons why startups move so much faster: many of these roles collapse into single people, and iterations happen in a quicker memory space: their own brain.

The problem

Those expensive structures were built as a tradeoff. We had no alternative, so we accepted coordination overhead: a much less efficient memory space where more people meant quadratically more communication channels.

Planning used to take weeks. Design took dozens of iterations. Code took weeks to write. QA meant dedicated teams for days. Not because the work itself was that slow, but because of the communication overhead: the back and forth, the meetings, the calls, the constant alignment. The memory space where this work happens is distributed across people, and keeping it in sync is expensive.

Layers of management emerged to handle it. Endless meetings and long sprint cycles to keep everyone aligned. We tolerated all of it because the actual work of writing code was expensive enough to justify the overhead.

What changed

Two things shifted at roughly the same time, and together they changed the equation:

• Context expansion: LLMs give everyone instant access to a much broader context across domains. You no longer need years of experience in a field to understand its fundamentals. The knowledge that used to live in experts' heads, in documentation nobody read, in tribal knowledge passed down through mentorship, is now accessible in seconds. The context window of a single person just expanded dramatically.

• Skills democratization: Generative AI acts as a great equalizer, pulling everyone toward the same competent baseline. Writing code, designing interfaces, crafting copy, analyzing data: these used to require dedicated specialists. Now the gap between a novice and a mid-level practitioner has collapsed. Anyone with taste and direction can produce solid work in domains they've never formally trained in.

At its core, we made every single individual potentially a generalist, leveraging AI for the skills they don't have. They haven't become experts. They're not specialists in any of it. But on a day-to-day basis, you don't always need expert craftsmanship for every single thing you don't quite know how to do.

Now? That same problem doesn't require three teams, four meetings, and two sprints to solve. With these capabilities, you don't need constant help from specialists. You don't need to wait for alignment. You can move with far more agency, making decisions and iterating without the overhead of coordinating across the human chain.

The structures we built for decades suddenly look inefficient. The tools we have now let us do roughly the same work with a fraction of the people. The tradeoffs we accepted no longer make sense when the constraints that justified them have changed.

Back to basics

If the constraints have changed, what actually matters now? I keep coming back to two things: ownership and accountability.

Someone needs to own the solution. Someone needs to be responsible for keeping it working. Everything else is negotiable: the roles, the titles, the team structures, the processes.

The person who owns it might write every line themselves. They might generate half of it with AI. They might still coordinate a team. The "how" is wide open. What matters is that when something breaks, there's a human who cares enough to fix it.

What comes next

New structures will emerge. They won't be based on who writes code or who designs interfaces. They'll be based on who can evaluate quality. Who has taste. Who can judge whether generated code is good or garbage. Who has the vision to know what to build next.

Maybe Rick Rubin was spot on when he said the value he brings comes from his taste and the decisiveness to be vocal about it.

The work becomes:

In the age of AI, the output we produce will be a function of our personal agency and the output of the LLMs we use. output = agency × llm

There will be people who explore new directions. People who ship fast and learn from failure. People who hold the line on quality when everyone else wants to move faster. Our competitive advantage won't be our knowledge per se, but how sharply we can instinctively filter the output of the machine using it.

This doesn't mean domain expertise disappears. If anything, we'll need it more as we produce more software. Complex systems still require people who deeply understand security, databases, distributed systems, compliance, and domain-specific problems. The difference is that the expertise matters more than the process around it.

The org charts, the career ladders, the sprint ceremonies, even the definition of "software engineer" are all up for debate now. None of it should be taken for granted. When need and ownership can be so close, or even collapse into one, the definitions we've relied on for decades start to sound arbitrary.

The old way still works

This doesn't mean the traditional approach is suddenly wrong.

Plenty of companies don't have product managers. Plenty still use waterfall. Many still deploy to production by uploading files via FTP. Many companies will work the old way for years to come, and generate billions doing so.

The challenge is to be open-minded about responsibilities blending and ownership expanding. To stop pretending there's only one way to build software. The disruption opened up possibilities that didn't exist before, and those will emerge regardless of what your opinion on AI is.

No reason for anger

We can't be angry at any of this.

If you're old enough, you know that we literally made this up. Product managers weren't a thing. Sprint planning wasn't a ceremony. The frontend/backend split wasn't obvious. We invented these structures as we went along, solving problems as they appeared, copying what seemed to work.

We created these roles and principles because we needed them. They served us well for decades. Now the context has shifted, and we get to invent new ones.

Adapting is what brought us here in the first place. It's what will take us forward.

Looking forward

I'm optimistic about this. I have to be. I'll hopefully spend the next 30 years in this industry, and I'd rather be excited about what's coming than nostalgic for what worked before.

The disruption isn't comfortable. Watching familiar structures dissolve is unsettling. But discomfort is where progress lives. The best engineers I know are already experimenting, already adapting, already rethinking how they work.

Ownership and accountability don't change. The tools we use to exercise them? Those are wide open.

I might be completely wrong about all of this. But it would be fun to read these words in a few years, once we know what actually happened.

Let's see what we build.

---

This might look like a weird post to care about in the context of cooking... but it isn't really.

This is a great time for one-person projects and small teams. They just gained a massive amount of leverage, and can now compete at a level that previously required much larger organizations. This project, and others like it emerging on the internet, are on the cusp of the reductionism of software. The need and ownership have collapsed into a small handful of people or a single individual.

For context, most of the code in fork.club was written by hand over a period of about 3 to 4 years. This isn't about AI writing everything from scratch. It's about how the tools we have now make it possible for a tiny team to build, maintain, and evolve what previously required teams.

Author: Jorge Bastida
Published: January 23, 2026
RFD: #0011

If you'd like to discuss this RFD, share your thoughts, or simply chat about it, feel free to reach out to me - To stay up to date with the project's development, you can follow me on X