For most of my career, a large part of software development involved wrestling with syntax.

You learned the quirks of a language. You memorised framework conventions. You spent hours moving code around, fixing compiler errors, searching for the missing semicolon, or tracking down the one condition that caused everything to break.

That work still exists, but it is becoming increasingly difficult to argue that it is where engineers create the most value.

Claude can write code faster than any human. Given the right context, examples, constraints, and access to the necessary tooling, they can often produce implementations that are not just faster, but more consistent than what most developers would create themselves.

The bottleneck is no longer typing.

The bottleneck is understanding.

A Case for Design Patterns

Do you remember design patterns?

Back in 1994, the Gang of Four published Design Patterns: Elements of Reusable Object-Oriented Software. The book became foundational reading for a generation of developers because it documented proven solutions to recurring problems.

The Observer pattern. Factory pattern. Strategy pattern. Singleton. Whether you loved them or hated them, they represented something important: accumulated knowledge.

Rather than solving the same problem from scratch every time, developers could rely on patterns that had already been tested in the real world.

The idea never disappeared. It simply evolved.

Frameworks introduced their own conventions. Architectural styles emerged. Front-end component libraries became collections of reusable solutions to common interface problems. Entire organisations built internal platforms around preferred ways of working.

The underlying principle remained the same.

When a problem occurs repeatedly, it is worth documenting a solution that can be reused.

That principle becomes even more important in a world where AI is responsible for much of the implementation.

You are no longer primarily responsible for typing the pattern.

You are responsible for recognising when the pattern applies.

The quality of the outcome increasingly depends on whether the system has access to proven approaches, clear examples, and well-defined constraints. The engineer's job shifts from constructing every solution manually to curating the collection of solutions available to the system.

Patterns become leverage.

Your Role in an Agentic World

Many engineers still spend large portions of their day fixing small implementation issues.

A naming inconsistency here.

A missing validation there.

A repeated bug that appears in slightly different forms across multiple services.

These issues need attention, but repeatedly solving them at the implementation level may no longer be the best use of engineering time.

If an AI agent keeps making the same mistake, fixing the generated code is often treating the symptom rather than the cause.

The better question is why the mistake was possible in the first place.

Should the instructions be clearer?

Should the examples be improved?

Should there be stronger validation?

Should an existing pattern be documented and reused?

The most effective engineers increasingly think about the environment in which solutions are produced rather than the solutions themselves.

They improve guardrails.

They refine instructions.

They capture institutional knowledge.

They create systems that make the correct outcome the easiest outcome.

The focus shifts from writing code to shaping the conditions under which code is written.

Systems Thinking

Once patterns, principles, and guardrails are in place, the real challenge becomes understanding the broader system.

Software has never existed in isolation.

Every technical decision influences users, business goals, operational processes, support teams, security requirements, and future development work. The best engineers have always understood this, but the shift toward AI-assisted development makes it impossible to ignore.

When implementation becomes cheaper, understanding becomes more valuable.

The ability to see connections across domains becomes a differentiator.

Understanding customer problems.

Understanding product strategy.

Understanding usability.

Understanding quality.

Understanding organisational constraints.

These skills were often treated as adjacent to engineering. Increasingly, they are becoming central to it.

Engineers who can connect technical decisions to business outcomes become valuable contributors far beyond implementation. They help translate vision into strategy and strategy into execution.

Once the direction is clear, and the patterns are established, implementation becomes the comparatively easy part.

This is why investing in broader skills matters.

Product thinking.

Design.

User research.

Quality assurance.

Communication.

Systems design.

None of these are new disciplines. They have always mattered. What is changing is their relative importance.

Fifteen years ago, becoming a better engineer already meant becoming more than a person who writes code.

Today, the tools are making that reality impossible to ignore.

The Opportunity

The transition can feel uncomfortable because many of us built our professional identities around implementation.

We took pride in knowing the language details, framework internals, and clever techniques that allowed us to build things efficiently.

Those skills still matter.

But they are no longer the entire job.

The opportunity in front of us is to move up a level.

To spend less time moving code around and more time understanding why the code exists.

To spend less time solving the same problem repeatedly and more time creating systems that prevent the problem from recurring.

To become experts in patterns, principles, products, and systems.

The typing was never the point.

Understanding the problem always was.

Now the tools are finally forcing us to act like it.