The Software Engineering Kanagawa Moment
The wave is coming
The Great Wave off Kanagawa can also be seen as a metaphor for upheaval — a massive, unstoppable force reshaping the world beneath it. Created during Japan’s Edo period, just before the country’s forced opening to the West, it reflects anxiety and awe in the face of external, transformative change.
Software engineering is having its own Great Wave moment. Some engineers aren’t looking up.
The Wave Is Here
Language models work best in areas where language goes in and language comes out. Two domains fit that bill perfectly: law and code.
Code was always going to be first:
There is much more openly available material to train language models on.
The work product is entirely verifiable automatically: you can run tests and confirm the product works, there is less opinion here.
Software engineers understand software engineering better so that’s where they focus more.
It doesn’t have regulation: people pay lawyers because they have a fancy degree and a big sign on the door, not because they can’t write the contract themselves.
From autocomplete and refactoring tools, we now have coding agents that can turn JIRA tickets into pull requests. These tools are no longer novelties; they’re rapidly evolving into the new normal of how software gets built.
There are effects on the ground right now.
The junior software engineer hiring market has slowed to a crawl. Coding agents are attracting intense investment and attention.
Some of it is preemptive. Organizations feel that a change is coming and are front-running it by slowing down hiring and pushing employees to help replace themselves with AI.
I think most software engineers are currently underestimating the magnitude of what’s going on. This is very human.
It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
American author Upton Sinclair.
We’re like a farmer in the 1800s, watching the first tractor show up.
What happens next?
The Scope of Automation
Automation in software is coming from two directions:
Live coding assistants (“copilots”): tools embedded in your IDE, helping you write, refactor, and debug code in real time.
Autonomous agents: End-to-end systems that consume a task description (like a JIRA/Linear ticket) and produce working code, with tests, docs, and commit messages.
These two forces are converging. What’s left in the middle?
Here’s what coding agents are initially better at:
Clear, small, well-defined tasks (e.g. “add logging here” or “update dependencies”).
Repetitive, tedious, self contained work.
Writing or updating tests.
Making proactive changes based on external inputs (like newly published CVEs or deprecation warnings).
But they don’t operate in a vacuum. Human engineers still play a key role in setting the stage.
Aside: Vibe Coding
Much of the buzz around “Vibe Coding” — non-professionals using AI tools to build apps or automate tasks — is a red herring.
This isn’t where the real upheaval is coming from. Vibe coding is like owning a high-end oven at home: it enables more people to experiment and create, but it doesn’t replace professional chefs in restaurants.
Similarly, people casually using GPT to script a spreadsheet or using a “no code” tool to build a personal app aren’t threatening the software engineering profession. They’re expanding the ecosystem.
The real disruption comes from tools that automate professional workflows.
How Humans Make AI Coders Effective
For coding agents to succeed, they require some groundwork. That means:
Conventions and standards: Define how code should look, how features should be built, how commits should be structured, where does certain code go, what frameworks are used.
Environment setup: Ensure isolated, clean environments can be spun up easily.
Testing infrastructure: Make it easy and automatic to verify correctness.
Well-scoped tasks: Break work down into small, well defined chunks.
These are all things great software engineers already do — but now they’re not just good hygiene. They’re enabling huge gains from using AI.
So What’s Left for Humans?
Here’s what doesn’t get automated — at least not yet:
Understanding the business: Figuring out what needs to be built, why it matters, and how it should work.
Product design: Translating real-world needs into features and user experiences.
Systems setup / scaffolding: Choosing the right tools, frameworks, and services. Setting up the project structure, CI/CD, observability, testing strategy, and more.
Defining the rails: The constraints, defaults, and guardrails that keep a codebase sane.
This is essentially a mix of today’s senior software engineer, entrepreneur and product designer.
Maybe it’s still called “software engineer.” But it’s not what most CS degrees train you for. It’s definitely not about implementing some function or building a certain feature.
Is This All There’s To It?
To be honest, this feels incomplete. Like I came to some simple solution, “do this and not that, be a better engineer and things will be fine”.
The stopping point I’ve chosen feels arbitrary.
Nothing tells us that LLM can’t do systems setup and scaffolding, choose frameworks and set standards, given a product description.
When agriculture mechanized, it’s not that millions of people who worked in farming just switched to farming differently. These jobs were absolutely totally gone. Millions moved to cities, eventually working different jobs that have nothing to do with farming.
The same kind of transformation is coming for software. There are over a million software engineers in the U.S. alone. That’s a lot of people standing in front of a very large wave.
What To Do — Now
For all engineers:
Spend serious time with LLMs and coding agents. Work and build with products (coding assistants, coding agents) as well as frameworks (LLMs, agentic frameworks, MCP etc).
Be critical of your day-to-day workflow. What can be automated? What is still frustratingly manual? Should I be writing this code by hand right now?
Embrace an AI-heavy workflow. This is the world you’re going to be working in.
Learn more about product and business. Figure out what sells and what doesn’t. What solves a problem and what doesn’t.
For junior engineers:
This is the group that appears most vulnerable, at least now.
Focus on end-to-end product building. Don’t just solve isolated problems — build full apps, APIs, services. Understand everything that goes into professional level working software.
Learn how tools and platforms fit together: cloud services, CI/CD, observability, infrastructure.
Master the "rails" work: setting up environments, managing dependencies, choosing good defaults.
Study how real products get made. Go beyond tutorials and into product thinking. Try to build your own real working versions of popular successful products.
This isn’t the end of software engineering. But it is the end of one version of it. I don’t know what version comes after this. I do know we don’t get to stop the wave that’s coming.
Enjoyed this read Pasha!
I believe your article title should be 'The Software Engineering Kanagawa Moment' not 'Kawagara'.