Crossing the Chasm for Developers

I’ve spent the last four years crossing a divide — from writing code the old way, by hand, to handing more and more control over to LLMs as they keep getting better.

I say that as an engineering leader and as an individual contributor. This isn’t a position paper. It’s what I’ve watched, and what I’ve had to learn myself.

I started where a lot of people started: GitHub Copilot and tab completion. Helpful. Fast. Still basically me driving every line.

Then I moved into Cursor and started working in a more agentic way — ask it to plan first, revise the plan, then build. That changed the shape of the work. I wasn’t just accepting the next token. I was directing an agent through a loop.

From there I went into Claude Code in the terminal. Same opportunity to plan and build, but I started digging harder into how to set things up so the output was reliable — not lucky. Across Claude Code, Cursor, and other tools, that meant learning the boring-looking stuff that actually pays off:

• Mastering Claude Code, Cursor, and how the underlying models behave
• Establishing repeatable context through markdown files
• Skills
• Rules
• Claude settings
• Design guidelines
• Frequent updates to all of the above to fine-tune over time.

That has been the real payoff for me. Understanding how to manage and wield the tooling on top of the LLM — not just chatting with a smart model — is the skill.

Models like Claude Fable make this hard to shrug off. The capabilities are there. The question is whether you cross.

Crossing the chasm

Geoffrey Moore’s Crossing the Chasm is a marketing book. It describes the gap between the early market — people who want the newest thing and will live with a minimum feature set — and the mainstream market — people who want a complete solution and convenience. That gap is the chasm. A lot of products die in it.

Like a successful product in the market, developers also have a chasm to cross if they want to remain relevant and have the valuable skills needed to succeed in the coming years.

On one side is the old way of writing software. On the other is the new way — agentic work with LLMs, set up so the output is consistent and reliable. Right now the early adopters are ahead. And the chasm is getting wider as the models get better.

The Left Bank

On the near side of the chasm are developers who insist on doing it the old way.

They have a pessimistic view of what LLMs can do. In my experience that pessimism is mostly framed by ignorance — and by an unwillingness to experiment and learn. They poo-poo the tools. They put their head in the sand. They keep writing every line by hand like that is still the default path to good software.

Skepticism without curiosity is just a stall.

The Right Bank

On the other side are developers who went through the learning curve.

They adopted early. They experimented often as the models changed. They put in the work to battle through prompting — the awkward phase where the tools feel uneven and you are tempted to quit. Then they elevated past prompts alone. They learned how to configure the environment. How to set context. How to build workflows and skills that produce deterministic output in an efficient way.

That is the real mastery: harnessing LLMs so the work comes out better than what you used to do by hand.

I still understand that in some cases hand-coding is the right call. Those cases are getting fewer and further between.

The Competition is Already Across

Here is the part a lot of developers do not want to sit with.

Non-technical people no longer face the same huge hurdle of learning code syntax and architecture first. LLMs can generally make the right choices — especially if someone has technical inclinations but lacks the years of experience. If they are determined to research, ask the right questions, and let Claude guide them, they can build things that would not have been possible for them before.

That closes the gap between what a developer could offer an organization in the traditional sense and what a non-technical product manager or marketing person can ship. It depends on the individual. Always has. But the floor moved.

There is still a technical craft in managing LLMs properly. That is where developers should focus now — not on the trivia of every line of code, and definitely not on poo-pooing the tools while insisting the old way is still the path.

Product managers have a version of this too. The idea that things can be built quickly with LLMs has already closed delivery timelines. What I am not seeing enough of is PMs producing the technical artifacts that used to eat their calendar — PRDs, user stories, the revision loops that made that work tedious. Same as writing code: with the right skill and project setup, those artifacts do not take that much time anymore.

A team that produces good user stories, ingests context, and hands work off cleanly to engineering is what product managers should be aiming at. They need to learn the technical skills of their own craft. AI is encroaching on their space as well.

Same story for product designers. Producing high-quality designs by hand is no longer the whole job. Producing deterministic designs — managing that process so the output is consistent — is a skill. They have a chasm to cross too.

The Handoff is The Product

Developers still have an upside here. They are the technical staff. But the biggest lever for an organization that wants to build faster and more efficiently with AI is not a better autocomplete in the IDE.

It is the whole pipeline.

The work that matters is managing the handoff from product to engineering so context can move — from the LLM on the product and product design side into the context and LLMs on the development side. PRDs, stories, design decisions, constraints: all of it needs to transfer cleanly, not get re-explained from scratch in a chat window three weeks later.

If only engineering crosses the chasm, the org is still stuck mid-gap. The whole pipeline needs to be managed agentically if you want to speed up delivery and scale in an age of AI.

So Cross

Writing good code is table stakes. In most cases, writing it by hand is probably not needed anymore. The skill worth learning is how to produce reliable work from tools that are not reliable by default — and how to set up a team so that work survives the handoff from product to delivery.

Don’t put your head in the sand. Don’t poo-poo the models because you haven’t put in the reps. Don’t treat the IDE as the whole game.

Experiment. Set context. Build workflows that make the output repeatable. Teach product and design to do the same. Get the handoff right.

The chasm is getting wider. The people who already crossed are not waiting for you.