I Was an Engineer at Meta. AI Changed Everything I Knew About Building Software.

I spent years learning how to write good software. How to think about architecture, structure code, build reliable systems, and work within engineering organisations where hundreds or thousands of people contribute to the same product. At Meta, I experienced what it means to build technology at an extraordinary scale, where specialisation, technical standards and carefully designed processes are essential to keeping complex systems running.

Those lessons shaped the way I thought about engineering. For most of my career, I believed that building great software required assembling the right specialists, establishing clear responsibilities and creating processes that allowed everyone to contribute effectively. The better the organisation, the better the software it could produce.

I still believe in the importance of great engineering. But over the past two years, something fundamental has changed. And it’s not simply that AI can now write code.

Today, as the CTO and cofounder of RHISE AI, I’m building software in ways that would have seemed almost impossible just a few years ago. The tools have changed, certainly, but the more interesting transformation is happening in how we work together, how we organise our teams and what we expect an individual to be capable of creating.

I increasingly believe that we’re witnessing one of the most significant changes in the history of software engineering. Not because engineers are becoming unnecessary, but because the boundaries that once defined engineering roles are beginning to disappear.

We built organisations around the limitations of individuals

For decades, software companies have organised themselves around specialisation. Frontend engineers built interfaces, backend engineers handled infrastructure and business logic, QA engineers tested what everyone else produced, designers created experiences, and product managers coordinated the process.

This structure made sense. Developing expertise took years, and moving between disciplines required considerable effort. A brilliant backend engineer wasn’t necessarily equipped to design an interface, and a talented product designer couldn’t simply implement a complex feature.

But specialisation came with a cost that we rarely questioned: coordination.

An idea would become a product requirement. That requirement would become a design. The design would be handed to engineering. Engineering would implement it, QA would test it, and eventually, after multiple rounds of feedback, the feature would reach users.

We became so accustomed to this process that we began to treat it as an inherent part of building software. In reality, much of that organisational complexity existed because of the limitations of the tools available to us.

AI is beginning to remove some of those limitations.

Today, an engineer can explore an unfamiliar codebase, develop an implementation, generate tests, investigate errors and build a working prototype with the help of AI coding agents. Work that previously required several people or multiple stages can increasingly happen within a single development flow.

The implication isn’t that everyone suddenly becomes an expert in everything. Understanding architecture, security, scalability and reliability remains essential. But the distance between having an idea and turning it into working software has become dramatically shorter.

And when that distance changes, the organisation built around it must change too.

We had to become beginners again

At the beginning of 2026, something interesting started happening inside our engineering team at RHISE AI. One of our youngest junior engineers was consistently producing some of the highest volumes of code in the company. He wasn’t our most experienced engineer, and he hadn’t spent a decade building complex software systems. In fact, I began to wonder whether his lack of experience with traditional engineering practices was precisely what gave him an advantage.

He had never really learned to build software the old way. He wasn’t carrying years of habits about how code should be written, how long certain tasks should take, or which parts of development needed to be done manually. Working with AI was simply how he understood engineering. He approached problems differently, moved quickly between ideas and implementations, and seemed remarkably comfortable allowing AI to handle parts of the process that more experienced engineers were accustomed to doing themselves.

What made this particularly fascinating was watching some of our most experienced engineers respond. We had backend engineers with decades of experience, people who had built sophisticated systems and understood software architecture at a level that takes years to develop. And suddenly, they were asking one of our youngest colleagues questions that would have seemed unusual just a year earlier. How are you doing this? What’s your process? How do you verify the code? How do you know the AI hasn’t made a mistake?

Those were exactly the right questions. The interesting part was who was asking them.

For most of my career, engineering knowledge flowed in a fairly predictable direction. Senior engineers mentored junior engineers. Experience gave you an understanding of what worked, what didn’t, and how to avoid costly mistakes. That remains valuable, but for the first time, we were seeing something different. The people who had spent the least time working within traditional engineering constraints sometimes had the most to teach us about this new way of building.

It became clear that simply giving everyone access to AI coding tools wasn’t enough. We needed to rethink how we worked.

So earlier this year, we brought the engineering team together and decided to approach the problem almost as beginners. We examined our workflows, questioned our assumptions and started relearning what it means to be a software engineer in an age when AI can write, modify, test and explain substantial amounts of code.

We had to reconsider questions that previously seemed settled. How should an engineer approach a new feature? When should they write code themselves, and when should they delegate to an agent? How do you review something you haven’t written line by line? How do you maintain architectural consistency when the speed of implementation increases dramatically? And perhaps most importantly, how do you ensure that writing more code actually results in better software?

It was a humbling experience, particularly for those of us who had spent years mastering the previous way of working. But it was also liberating. We weren’t abandoning everything we’d learned. We were combining the judgement that comes from experience with an entirely new set of capabilities.

And the results became visible in what our team could ship. At some point, something clicked. In a single week, we pushed more than in the six weeks before it combined.

The graph tells part of the story, but I think the more important change was cultural. We stopped treating AI as an additional tool that engineers could use when convenient. We started treating it as a fundamental part of how engineering happens.

That shift also changed the opportunities available to people across the team. Our QA engineers, for example, began moving beyond testing into direct software development. People who understood our product deeply but previously relied on other engineers to implement changes could now contribute to building those solutions themselves.

This wasn’t a transformation we were imagining for the future. It was happening inside our company, and it was changing how we thought about roles, responsibilities and the capabilities of individuals.

What stayed with me most was the realisation that experience and expertise were no longer quite the same thing. Someone could have decades of experience building software and still be a beginner at this new way of working. Someone else could have only recently entered the profession and already be remarkably proficient at it.

For an engineering leader, that’s a powerful lesson. The challenge isn’t simply to introduce AI tools into an existing organisation. It’s to create an environment where everyone, regardless of seniority, is willing to learn from one another and reconsider how things should be done.

We had to become beginners again. And I think it made us better engineers.

Our QA engineers became software engineers

Perhaps the clearest example of how much our organisation has changed is what happened to quality assurance.

Traditionally, QA engineers have been responsible for identifying problems, reproducing bugs and ensuring that software behaves as expected. Their work is essential, but the structure of most engineering organisations has kept them separate from the people writing the code.

A QA engineer might discover a problem, document it, create a ticket and wait for a developer to investigate and implement a solution. The process could involve several conversations, multiple reviews and considerable time.

Since the beginning of this year, we’ve experienced a very different reality at RHISE AI.

Our QA engineers have been able to move into software development, contributing code and taking greater responsibility for implementing solutions. With AI coding tools, they can investigate the underlying code, propose fixes, write automated tests and participate directly in the engineering process.

Think about what a good QA engineer already understands. They know how a product should behave. They understand edge cases, notice inconsistencies and anticipate the things that could go wrong. Historically, their responsibility was often to identify problems and send them back to someone else.

Now that knowledge can translate much more directly into building the solution.

What I find particularly exciting is that this isn’t simply a productivity improvement. It’s an expansion of human capability. Someone who understands a product deeply no longer needs to be limited by their ability to manually write every line of code.

Of course, generating code doesn’t automatically make someone an experienced engineer. Reviewing changes, understanding systems and taking responsibility for production software remain essential. But the barriers to contributing have become dramatically lower.

And when people can contribute beyond the boundaries of their original job descriptions, the entire structure of a company begins to change.

The product itself is becoming the prototype

Another major change is happening before the first line of production code is written.

Traditionally, building a product involved a long sequence of research, requirements, wireframes, designs, technical planning and implementation. Each stage served a purpose, but each also introduced time between the original idea and the moment someone could experience it.

Today, that process is becoming much more fluid.

At RHISE AI, we’re building Lucie, a personal AI designed to help people navigate their lives with greater intention, clarity and freedom. Many of the experiences we’re developing are difficult to fully understand through documents or static designs alone.

How should a personal AI communicate with someone? When should it offer help? When should it remain quiet? How should it understand context without overwhelming the person using it?

These aren’t questions that can always be answered in a meeting or a design document. Often, the best way to explore them is to build something, experience it and observe how people respond.

AI makes that process significantly more accessible. Instead of spending weeks preparing an idea for implementation, teams can increasingly create functional prototypes and learn directly from the experience.

This has changed how we think about product development. We no longer need to organise every stage around a separate specialist or a lengthy sequence of handoffs. The people closest to the problem can participate much more directly in exploring and building the solution.

This doesn’t eliminate the importance of research or thoughtful design. It changes how research and design can happen. Rather than separating discovery from implementation, we can bring them closer together.

The product becomes part of the thinking process itself.

And the faster we can move between an idea, a working experience and real feedback, the faster we can discover what genuinely matters to users.

The engineering organisation is becoming flatter

Once you begin to see these changes, it’s difficult not to question the traditional structure of engineering teams.

If more people can contribute across disciplines, why should every decision travel through several layers of coordination? If a small team can take responsibility for an entire feature, why organise its work around so many separate handoffs?

At RHISE AI, this isn’t simply a theoretical question. We’ve experienced how quickly traditional boundaries can become less relevant when people have the tools and confidence to work beyond their original specialisations.

I don’t believe the answer is to eliminate management, remove specialists or pretend that complex software no longer requires deep expertise. Large systems still demand careful architecture, strong technical leadership and rigorous quality standards.

But I do believe that the most effective engineering organisations will increasingly be built around ownership rather than narrowly defined responsibilities.

Instead of asking how many frontend engineers, backend engineers and QA specialists are required for a particular project, we can begin asking a different question: what is the smallest capable team that can take responsibility for delivering an excellent outcome?

That is a fundamentally different way of thinking about organisational design.

It also changes what leadership looks like. A technical leader’s responsibility becomes less about coordinating every individual task and more about creating the conditions in which people can make good decisions, work independently and maintain high standards.

The result may be smaller teams, faster development cycles and fewer organisational layers. But the real benefit isn’t simply reducing headcount. It’s reducing the friction between understanding a problem and solving it.

The economics of building software are being rewritten

This transformation should interest more than engineers.

For decades, the economics of software companies have been closely connected to the number of people required to build and maintain their products. When companies wanted to accelerate development, they often hired more engineers. When products became more complex, they added more specialised teams and management structures.

AI challenges the assumption that development capacity must increase proportionally with headcount.

A small team equipped with powerful coding agents may be capable of exploring more ideas, building more prototypes and delivering more functionality than a similarly sized team could have achieved a few years ago.

For founders, CEOs and CFOs, that has potentially enormous implications. The capital required to bring a software product to market may decrease. Smaller companies may be able to compete in areas that previously demanded substantial engineering resources. And organisations may find that their competitive advantage depends less on the size of their workforce and more on the quality of their decisions.

But there is an important distinction between producing more software and creating more value.

AI can generate enormous amounts of code, but that code still needs to be understood, tested, secured and maintained. A company that uses AI to produce unnecessary complexity faster hasn’t necessarily become more efficient.

The real opportunity is to build organisations that spend less time coordinating work and more time solving meaningful problems.

I don’t think the ambition should be to create companies with as few employees as possible. It should be to give talented people the ability to accomplish things that previously required much larger organisations.

That is a far more exciting possibility.

What makes a great engineer is changing

When I think about the engineers who will thrive in this new environment, I don’t necessarily think about the people who can write code the fastest.

I think about people who understand systems, ask good questions, recognise problems before they become expensive and have the judgement to distinguish a convincing solution from a correct one.

These qualities have always been valuable. But when the mechanical process of writing code becomes increasingly automated, their importance grows.

A great engineer needs to understand what should be built, why it matters, how different components interact and what might happen when something goes wrong.

They also need curiosity. The willingness to experiment with unfamiliar tools, question established practices and continuously rethink how they work.

Perhaps most importantly, they need a sense of responsibility for the outcome.

AI can help produce an implementation, but it cannot replace the human responsibility to understand whether that implementation is appropriate, reliable and genuinely useful.

In some ways, I think engineering is becoming less about the act of coding and more about the art of building.

And that opens up extraordinary possibilities for people who may never have considered themselves software engineers.

We’re still at the beginning

I don’t think anyone has fully figured out what an AI native engineering organisation should look like.

At RHISE AI, we’ve spent much of 2026 experimenting, learning and questioning how we work. Some of the processes we relied on a year ago already feel unnecessary. Other practices, particularly those involving quality, security and technical judgement, have become even more important.

I expect our organisation to continue evolving as the technology improves.

But one thing has become increasingly clear to me: the software companies of the future won’t necessarily look like smaller versions of the companies we built in the past.

They may be organised around an entirely different understanding of what individuals can accomplish.

Having spent much of my career learning how to build software within traditional engineering structures, I find this moment extraordinary. It’s rare to experience a technological shift that makes you reconsider not only the tools you use, but the assumptions you’ve built your entire profession around.

And perhaps the most exciting part is what this means beyond engineering.

When more people can turn their ideas into working technology, when smaller teams can solve increasingly complex problems, and when building software becomes more accessible, we expand the number of people who can participate in creating the future.

Earlier this year, I watched experienced engineers ask a junior colleague to teach them how he worked. We sat together and reconsidered practices that many of us had spent our careers perfecting. We learned from one another, regardless of seniority, and discovered that being willing to become a beginner again was perhaps one of the most valuable qualities an engineer could have.

That experience changed how I think about my profession.

Because ultimately, the purpose of software engineering was never to write more code, build larger teams or create increasingly sophisticated processes.

It was to solve problems and build things that improve people’s lives.

And sometimes, making progress means being willing to forget how you thought things had to be done.

We’re only getting started.