What Boris Cherny's "coding is solved" statement means for learners

I watched an interview this week with Boris Cherny, the creator of Claude Code, and I wanted to share some thoughts on it. He spoke at Sequoia's AI Ascent 2026 and said a few things that I know will be on a lot of people's minds in our community. Among them: "coding is solved." He also mentioned he hasn't written code by hand in 2026, and that he ships dozens of pull requests a day from his phone.

If you're learning to code right now, that's the kind of thing that can be worrying to hear. So I wanted to pull out the parts of the talk most useful for people in the Frontend Mentor community, share where I agree, where I'd add nuance, and what I think it all means in practice. The full interview is embedded below and worth a watch.

Boris Cherny in conversation with Lauren Reeder at Sequoia AI Ascent 2026 (~25 min).

A quick note before we get into it: Boris is talking about his workflow, on his codebase, at Anthropic. It's the leading edge, not the average. And even at the leading edge, the message isn't "don't bother learning." But there's definitely a big shift happening that's worth paying attention to.

"Should I even bother learning to code?"

This is the question I see most in our Discord, so let's take it head-on.

My honest answer is yes. And I'd say that even if Boris's setup were the norm tomorrow.

Whether you're hand-typing every line or working with AI agents, you as the engineer still have to understand what's being produced. You need to read the code an agent writes and know whether it's good or bad. You need to spot the patterns it's using, recognize when it's gone down the wrong path, and catch it when it's confidently wrong, which happens more often than people admit. Models have web search now, but they don't always use it, and they don't always know they need to. They can also fall back on patterns and techniques that are outdated, based on when their training data was cut off.

There's no shortcut to that level of understanding. The only way to build it is to learn the foundations yourself. Syntax, patterns, how data flows, why some approaches scale and others fall over. That part isn't going away. If you're working with AI as a learner, our guide on AI coding assistants for beginners goes deeper into how to use these tools without becoming dependent on them.

What is changing is what you do once you have those foundations. A few years ago, an entry-level engineer could spend their first year fixing bugs, writing tests, and shipping small tweaks. That's exactly the kind of work AI is good at now. So you need to move up the layers a bit faster. Get fluent in the syntax and patterns, then start handing some of the busy work to AI while you focus on the harder parts: architecture, product decisions, edge cases, and judgment calls.

Learning to code and learning to build software aren't quite the same thing. Code is the syntax and the patterns. Software is how everything fits together: scalability, maintainability, security, accessibility, performance. Both still matter. The good news is that AI lets you reach the "building software" layer earlier in your journey than was previously realistic, as long as you've put in the work on the foundations first.

The printing press analogy

One of the more interesting parts of the talk is when Boris compares this moment to the invention of the printing press. Before the printing press, around 10% of Europeans could read and write. Within 50 years, more literature was published in Europe than in the previous thousand years. He thinks software is on a similar path, just much faster.

I roughly agree. Tools like Lovable, Replit, and Bolt already let people with no coding background ship working software for themselves. A small business owner can build a booking app over a weekend. That's a real change. We wrote about this shift in more depth in our article on vibe coding, which covers where it helps, where it falls apart, and what it means for learners.

For Frontend Mentor learners, this has two sides.

The good side is that the floor is lower, which means the barrier to learning is lower. You can build credible projects faster, solve your own problems, and get something live for friends and family without years of build-up.

The harder side is that more people will be able to make things that look good. The bar for standing out has gone up. A couple of years ago, two or three intermediate-level portfolio projects could get you noticed. That's not really true anymore. The floor of "looks impressive" has been raised, so what counts as "stands out" has been raised too.

What replaces it? Bigger, more complete projects. Full-stack applications. Ideally something hosted online, with a database, with real users (even if "real users" is just you, your partner, and a couple of friends). A lot of companies are now hiring for what they call product engineers: people who can demonstrate self-direction, taste, and ownership, not just clean syntax. That's the bar now.

Domain knowledge is becoming more valuable

One of my favorite lines from the talk: "The best person to write accounting software is a really good accountant."

For anyone changing careers, that should be reassuring. I switched into web development at 29, after years as a personal trainer. The reason I started learning to code was that I kept having ideas for fitness apps and had no way to build them. Looking back, if AI tools had existed in 2014 the way they do now, I might have skipped years of hand-coding and gone straight to shipping a first version.

The point isn't that you should skip the fundamentals (we just covered why you shouldn't). The point is that your old career, your hobbies, your specific interests, all of that is now a real asset. It used to be the thing career-changers worried about. "I haven't been coding since I was a teenager." "I'm 35 and just starting." That worry made sense in a world where coding skill was the bottleneck. In a world where coding skill is becoming cheaper, domain knowledge is what's harder to come by.

If you're a nurse learning to code, your understanding of clinical workflows is rare and valuable. If you're a teacher, you know things about how learning actually works that engineers without that background don't. If you're coming from finance, law, logistics, or hospitality, that knowledge gives you an edge in any product targeting your old industry.

What if you don't have a previous career? You're 19 and learning your first language? You still have hobbies, interests, and pain points. Build for those. Build a tool for the game you play, the sport you follow, the thing you're into. Those projects do double duty: they give you genuine learning friction (which is where most of the real growth happens) and they make you stand out as a person, not just a CV.

Generalists across disciplines

Boris pointed out that everyone on the Claude Code team codes. Not just the engineers. The PM, the designer, the data scientist, the finance person, the user researcher, all of them write code. He thinks the future is generalists across disciplines, not just within engineering.

I agree, with caveats. Disciplines are disciplines because they have their own norms and ways of thinking. You don't develop design taste, product instinct, or backend judgment by reading about them. You develop them by doing them, badly at first, then better.

What does this mean for someone learning web development right now?

Stay focused on your core. If you're learning frontend, get genuinely good at frontend first. Foundations, accessibility, layout, state management, performance. Strong accessibility knowledge alone is a real differentiator in hiring conversations.

But don't be frontend-only by the time you're applying for jobs. About one in five entry-level roles we see are frontend-specific. The rest expect at least some full-stack range. Get a working understanding of backend: databases, APIs, auth, deployment. You don't need to go deep on every topic, but you need enough to ship full-stack projects. If you want concrete project ideas, our guide to 12 full-stack project ideas walks through how to take Frontend Mentor challenges and build them into proper full-stack apps.

Pick up some design and product sense as you go. Refactoring UI by the Tailwind team is a great place to start. Build something with one of our product challenges where you have to make your own design decisions instead of following a Figma file. That muscle, deciding what something should look like and do, is exactly the cross-disciplinary work Boris is talking about.

The trick is not trying to learn ten things at once. Go deep on your core, learn adjacent foundations, and then let just-in-time learning do the rest. When you hit a gap while building something, that's your cue to dig into that topic. That's how taste actually develops.

Is it the best time to build?

Boris's closing prediction is that there will be ten times more disruptive startups in the next decade because tiny teams can compete head-to-head with incumbents.

I think he's right, and I want to push back on the doom-and-gloom narrative that "software is dead." A lot of that is rage bait designed to drive engagement. The reality is closer to this: software-building is changing, the bar is moving, and there will be more opportunities for people who can actually build things, not fewer.

So does the traditional learner goal of "build a portfolio, get hired" still make sense? Mostly yes. The "get hired" part is still very real, and lots of people in our community do exactly that. It's also harder than it was a few years ago. Entry-level openings have decreased and competition has gone up. We dug into the current state of the market in detail in our guide on how to get a programming job in 2026, and it's worth a read if you're job-hunting right now. But "build a portfolio" has changed. A well-built weather app or to-do list won't move the needle on its own anymore. The bar is closer to: a more complete full-stack project, ideally hosted, ideally with some users, ideally solving a real problem (yours, your friends', or a small group of strangers').

That doesn't mean "go build a startup." For someone six months in, that's not useful advice and it usually leads to overwhelm and burnout. What is useful is building a real thing that real people use. Even if "real people" is three friends and your sister. Get it online. Give it a domain. Connect a database. Ship updates based on what they actually do with it.

That kind of experience teaches you more than ten tutorial videos. You hit problems you didn't expect. You discover gaps in your knowledge in the most efficient way possible: by needing the answer right now to keep going. That friction is where you actually learn.

Where to go from here

If I could leave you with one thing from all of this, it would be: build, build, build.

Build on Frontend Mentor. Use our design-led challenges to nail your foundations. Push yourself onto our advanced and guru-level projects sooner than feels comfortable. Take on our product challenges where you're collaborating with AI on design and product decisions, not just code. If you're confident hand-typing a guru-level challenge, also try building one by orchestrating AI agents and owning the quality of the output.

Every challenge now ships with AGENTS.md files that calibrate AI tools to your difficulty level, so you get help that matches where you are in your journey. This means you can use AI tools like Cursor and they'll adapt to your level and help you learn concepts and get unstuck without outsourcing your thinking to them.

Then go further. Build side projects around your hobbies, your previous career, or a pain point you have in your day-to-day life. Get one of them online. Use AI as a collaborator that lets you punch above your weight, not as a replacement for understanding what you're doing.

Boris's "coding is solved" line is a useful thing to think about, but the longer version of his argument is more nuanced and more hopeful than the headline. The work is changing. The bar is changing. The opportunities are changing too. For anyone in our community who's putting in the work, this is a good moment to be learning.

For another take on where the industry is heading, Addy Osmani's piece on the next two years of software engineering covers similar ground from a slightly different angle. It pairs well with this one.

If you've watched the talk and have your own take, drop it in our Discord. I'd love to discuss them with you!