Russell East's blog

Introduction

For a while now, it has been impossible to open LinkedIn, Hacker News, or X without seeing endless posts asking and debating a single existential question: Will AI replace software engineers? Seems like every week, a new autonomous coding agent or large language model promises to render human developers obsolete, fueling a cycle of tech anxiety and defense.

But I think we are asking the wrong question entirely.

The panic assumes that AI is arriving to disrupt a thriving, deeply intellectual craft. The reality is much quieter and far more uncomfortable. In many organisations, software engineering has already been reduced to ticket processing. We transitioned from creative system builders to assembly line workers long before the first LLM was trained. AI didn’t create this trend; it simply arrived after it had already begun.

When Engineers Solved Problems

If you go back 20 years, the daily footprint of a software engineer was vastly different. Teams were much smaller, and product teams operated with a lean, direct focus. We did not have dedicated DevOps departments, platform engineering teams, or isolated data teams to handle specialized tasks. Instead, we had fewer specialisations. As an engineer, you were expected to touch everything: you wrote the front-end and back-end, designed the databases, managed the deployments, and literally owned the build servers.

This lack of structural buffering meant engineers were naturally closer to customers. Because there was no complex game of telephone passing through multiple layers of product management, engineers were the ones designing, building, deploying, and supporting systems end-to-end.

Ultimately, engineers owned outcomes. This ownership materialized in very practical ways across the entire lifecycle of a project:

• Gathering requirements directly from stakeholders to understand the true business need.
• Designing databases from scratch, ensuring data models fit long-term goals.
• Building deployment scripts manually to safely push code to production environments.
• Supporting production directly, making you immediately accountable if something broke.
• Creating internal tooling to optimize the team’s workflow and fix engineering friction.

Engineers weren’t handed pre-packaged solutions or step-by-step checklists. They were given ambiguous business problems and trusted to figure out how to solve them.

Agile Was Never Supposed To Lead Here

When the Agile Manifesto was written, it was a radical document created by engineers, for engineers. It was an engineering discipline, not a framework intended for project managers. At its core, agile was a mindset; it wasn’t about what you did, it was about how you did it. It was about us, our craft, and our relationship to the work.

The origins of agile were deeply rooted in Extreme Programming (XP) practices, where technical excellence and adaptability went hand in hand. The goal was to establish tight feedback loops, commit to continuous improvement, and foster direct customer collaboration. Originally, agile tried to bring engineers closer to customers, eliminating bureaucratic walls so we could build better software.

Being agile simply meant wanting faster feedback and having the ability to pivot as the customer’s needs changed. Crucially, back then, the tickets or task breakdowns were created by the engineers themselves. A ticket wasn’t a top-down directive; it was our decomposition of the problem. It was how we chose to slice a complex engineering challenge into manageable pieces.

Somewhere along the way, the industry lost the plot. What began as an empowering engineering mindset was co-opted, turned upside down, and transformed into just another rigid delivery process. The very thing that had brought a group of engineering thought leaders together to challenge it in the first place.

The Rise of Ticket-Driven Development

Today, the digital board, whether in Jira, Azure DevOps, or another tool, is the centre of gravity for almost every software team. Regardless of whether an organisation claims to run Scrum or Kanban, this digital board has become the de facto operating system of modern tech companies.

This infrastructure caused a profound shift in how work is framed: we moved from solving problems to processing tickets.

• Before: The challenge was broad and meaningful: “We need a customer management system.”
• Now: The challenge is narrow and mechanical: “Add field X to screen Y.”

During backlog refinement, the conversation shifts away from the actual business problem. Instead, the entire ceremony becomes an exercise in assigning a number. We need to face it: estimates are just “guesstimate” guesses disguised as data. Yet, teams spend hours debating whether a task is a three or a five, because the primary goal of the meeting has become getting numbers on tickets.

The entire ecosystem is now governed by rigid mechanics:

• Acceptance criteria that define exactly what to code, leaving zero room for creative interpretation.
• Story points that turn abstract effort into a rigid currency.
• Velocity metrics that track how fast a team can burn through that currency.

This framework introduces dangerous systemic side effects. It creates local optimisation, where individual developers maximise their own output at the expense of the overall system. It causes a total loss of context and a loss of ownership, leading to reduced decision-making on the ground. Why think deeply about the architecture when the ticket tells you exactly which line to change?

Ultimately, we changed the definition of success. Success used to be measured by outcomes (the value we delivered to the business). Now, success is measured by outputs, how many tickets we moved to the right. The ticket became the hard boundary of an engineer’s responsibility. If it isn’t in the acceptance criteria, it isn’t our problem.

The Feature Factory

To compound the loss of agile as an engineering discipline, the power dynamic in tech companies shifted. Product management took full control of the process. Rather than collaborating as equal partners in problem-solving, many organisations began operating like assembly-line factories.

The pipeline became completely standardised and linear:
Business Problem → Product Vision → Backlog → Ticket → Engineer → Test → Release

In this assembly line, the engineer’s role has been deeply diluted. The daily routine is reduced to a repetitive, four-step cycle: implement the instructions, test the code, merge the pull request, and move on immediately to the next card in the queue.

When you treat engineers like factory workers, you fundamentally alter how technical decisions are made. A classic exchange happens every day in these environments: an engineer realises that a robust, correct solution to a problem is much larger and more complex than the product owner expected. The product owner, knowing they have to manage expectations with higher management or external customers, immediately pushes back.

To keep the assembly line moving, engineers are forced to compromise. They accept a simpler, short-term patch or hide behind the dreaded “MVP” (Minimum Viable Product) label. This compromise adds another heavy layer to the company’s technical debt catalogue, always accompanied by the empty promise of “we will fix that later.”

Corporate guidelines often state that engineers must follow “best practices.” But inside the feature factory, the true, unwritten engineering standard isn’t best practice; it is JFDI.

The most worrying aspect of ticket-driven development is not the process itself. It is what happens to the engineer after ten years inside that process. If every problem arrives pre-defined, every requirement arrives pre-refined, every architecture decision has already been made, and every task is reduced to a ticket, when exactly does an engineer learn how to discover requirements, formulate designs, evaluate trade-offs, and create systems from first principles?

Speed and output beat craftsmanship every single time.

The Quiet Disappearance Of Innovation

Innovation Used To Live Between The Tickets

Historically, some of the most impactful software innovations were never requested by a product manager or outlined in a business requirement document. They lived in the spaces between the tickets. Many of today’s engineering disciplines began as engineers solving their own problems. Continuous integration, deployment automation, developer tooling, internal frameworks, and observability platforms didn’t emerge because they appeared on a roadmap. They emerged because engineers were given enough ownership to improve the ecosystem around the product.

These projects emerged because engineers were curious, frustrated by friction, or simply driven by craftsmanship. They explored the wider ecosystem around the product to find hidden efficiencies. Today, that organic exploration is gone. In fact, you would be lucky if your engineers explore the backlog, let alone the broader technical ecosystem.

If It’s Not In Jira It Doesn’t Exist

The modern corporate landscape is governed by a hyper-rigid prioritisation and utilisation culture. Driven by the pressure for predictable delivery, management demands that every single hour of an engineer’s day be accounted for and mapped to an official corporate goal.

This creates an environment where if a task is not in Jira, it simply does not exist. But true innovation rarely begins as a ticket. Innovation usually starts with informal, creative sparks:

• “I wonder if…”
• “This seems painful…”
• “There must be a better way…”

When every minute must be allocated to a pre-approved user story, there is no room left for these sparks to catch fire. By optimising out the “inefficiency” of unstructured time, companies have inadvertently optimised out their own capacity to innovate from within.

True innovation requires slack in the system. It requires empty space on a calendar to experiment, fail, prototype, and think. Ticket-driven environments view empty space as inefficiency. Many organisations now rely on hackathons to stimulate innovation. The irony is that hackathons exist precisely because day-to-day engineering no longer provides enough space for experimentation. We celebrate two days of creativity because we’ve unintentionally removed it from the other 250 working days of the year.

Have We Stopped Teaching System Creation?

To be absolutely clear, this is not a criticism of the new generation of software engineers. It is a sharp criticism of modern engineering environments that rarely, if ever, give developers the structural opportunity to build and flex these critical skills.

Because we have spent years treating engineers as ticket-processors, we have fundamentally changed what it means to grow as a developer. This raises an uncomfortable question for the modern tech landscape: Could a typical engineering team today actually build a product from a completely blank sheet of paper?

When you strip away the layers of product management buffering, you have to wonder if a modern team can:

• Discover requirements directly by talking to users and navigating business ambiguity.
• Formulate a design that balances immediate needs with long-term architectural stability.
• Model the domain accurately without a pre-baked schema handed down to them.
• Identify technical trade-offs and confidently choose what not to build.
• Create a roadmap that sequences engineering milestones logically over months, not days.
• Operate independently without a steady stream of pre-written, pointed tickets.

By over-indexing on ticket execution, we are no longer teaching or practising the art of holistic system creation. We are training developers to be highly proficient at colouring inside the lines, but we have stopped teaching them how to draw the lines in the first place. How will these engineers become senior? How do they become architects?

DevOps, Platform Engineering And The Abstraction Trap

To understand how the modern engineering role became so watered down, we have to look at our infrastructure. Let’s acknowledge the good first: CI/CD was a massive improvement for our industry. DevOps solved real, painful deployment bottlenecks, and Platform Engineering solves genuine architectural complexity. The creation of Internal Developer Platforms (IDPs) has done wonders to reduce cognitive load, allowing developers to spin up environments with a single click.

However, we have walked right into an abstraction trap.

The fundamental purpose of any abstraction is to remove complexity, not to remove understanding. Unfortunately, the industry has confused the two.

Modern engineers certainly don’t need to know every single Kubernetes API or Terraform syntax by heart. But the abstraction shouldn’t insulate them from foundational operational realities. Engineers still deeply need to understand:

• How systems fail: What happens to the application when a downstream dependency drops or a network splits?
• How systems scale: What actually happens under the hood when traffic spikes, and where are the bottlenecks?
• Operational consequences: How does a simple code change impact memory, CPU, or database performance?
• Costs: What is the financial reality of writing highly inefficient code in a cloud-native world?
• Observability: How do we safely monitor, trace, and debug an issue across a distributed system?

When we abstract away the infrastructure so completely that developers have no idea where their code lives or how it runs, we destroy their ability to build resilient software. Platform engineering should empower developers, but ownership of the system’s runtime behaviour must ultimately remain with the engineers who built it. Another view, of course if certain engineers do know this, yet processing tickets excludes them from using or acting on this knowledge.

Platform Engineering removed operational complexity. Ticket-driven development removed engineering autonomy.

AI Changes Everything

This brings us to the ultimate turning point of our current era. The reason the tech industry is experiencing such widespread anxiety about AI is that we are looking at a total inversion of what makes engineering valuable.

Historically, implementation was incredibly expensive. Translating a business requirement into functional, production-ready code required deep technical expertise, time, and significant capital. Because it was difficult, writing the code was the premium skill.

Today, that reality is shifting overnight. Implementation is rapidly becoming cheap, fast, and highly commoditised. Modern generative AI can increasingly produce:

• Clean code across multiple programming languages in seconds.
• Comprehensive unit and integration tests based on basic inputs.
• Thorough technical documentation that updates automatically (never seen so much markdown).
• Complex boilerplate infrastructure and repetitive system scaffolding.

This shift forces us to confront a critical question: What happens to the software engineer when implementation is no longer the scarce skill?

The answer is that the centre of gravity moves. When the mechanical act of writing code costs next to nothing, the market value shifts squarely back to the human-centric elements of engineering: problem solving, keen judgement, systems thinking, clear communication, macroscopic architecture, and true ownership.

The deep irony, of course, is that these are the exact skills that have been slowly eroded from an engineer’s day-to-day responsibility over the last decade of moving tickets across the board. For senior engineers who lived through the previous generation and remember what it felt like to own an entire system end-to-end, flexing these muscles will feel natural, like returning home. But for a generation trained exclusively inside the feature factory, this paradigm shift will require a fundamental re-learning of the craft.

AI does not just represent a danger to engineers; it affects product managers/owners, too. So far, the tooling is very much a solo sport. Vibe coding is experimental, but a more serious relationship with AI requires context engineering, of which we are still adapting and still learning. Be it spec-driven development, Hypervelocity engineering, or just navigating Codex or Claude code with your own set of skills and agents. We don’t need tickets from the product anymore; we need the epic / big picture (the problem) as part of the context. Do we still need to work in two-week sprints, as you can implement a lot in two weeks with AI? Maybe with the return of the engineers, product owners will return to thinking about product vision and SWOT analysis of the competitors rather then slice and dicing requirements into tickets. The methodology needs to change again when we learn have to use AI as a team sport.

The Return Of The Engineer

To look forward is not to indulge in blind nostalgia. This is not an anti-AI manifesto, nor is it a call to completely dismantle the foundations of Agile. Both technology and frameworks have their place in modern development. Instead, this is an acknowledgement that the pendulum is finally swinging back. By taking over the repetitive, assembly-line mechanics of software development, AI is inadvertently paving the way for a renaissance of the craft.

The future engineer may look surprisingly familiar to those who remember the origins of the discipline. Stripped of the need to spend hours writing boilerplate code or manual test cases, the developer of tomorrow will return to the core responsibilities that defined the role twenty years ago.

They will need to:

• Deeply understand customer problems rather than blindly accepting pre-written feature descriptions.
• Design holistic solutions that account for architecture, performance, security, and long-term viability.
• Challenge assumptions and push back when a requested feature or business logic fails to make logical sense.
• Own outcomes end-to-end, measuring their success by the value brought to the business rather than the velocity of their sprint board.
• Work alongside AI as a high-level director, utilizing the machine to generate the bricks while they focus entirely on designing the castle.

We are entering an era where the implementation becomes vastly easier, but the thinking becomes significantly harder. The engineers who thrive will not be those who can write syntax the fastest, but those who can think the most deeply about the systems they build.

Conclusion

The job of a software engineer was never just to write code. The job has always been to solve problems. For a while, we confused the two because writing code was the most technically demanding part of the process. AI is simply exposing that mistake.

We spent decades building feature factories optimized for rapid delivery. In the process, we forgot that engineers are not conveyor belts. They are thinkers, architects, and problem solvers. The organisations that remember this truth will massively outperform those that do not.

Everyone in tech is currently on a journey where technologies and processes change rapidly—and as we have seen with the industrialization of Agile, change is not always for the better. Engineers who started their careers only knowing ticket-driven development face the biggest challenge. They are the ones who must adapt quickly. Growth now means learning how to understand the underlying business problem, conceptualizing holistic solutions, and developing deep insights into aspects of the system far beyond the repository. With AI tools at their disposal, their success will depend on their ability to provide the machine with the right context, constraints, and instructions.

We should not fear AI; we should welcome it.

For years the industry has asked engineers to behave like compilers, processing tickets through increasingly efficient delivery pipelines. AI is simply taking over the repetitive environment we built for ourselves. The opportunity now is to reclaim engineering.

Is AI threatening software engineering?

Or is it exposing what software engineering was always supposed to be?

The organisations that continue treating engineers as ticket processors will discover that AI processes tickets faster. The organisations that cultivate problem solvers will discover that AI amplifies them.

The future belongs to engineers who understand the problem, not just the implementation.

.