There’s a lot of interesting technology to learn. But telling people they’re being left behind unless they learn another 500 tools isn’t getting them excited. It’s making them want to leave the industry.

I’m saying this as someone who teaches this stuff and wants to keep learning it. I want to see what people are building and understand how these tools work. But I’m tired of digging through the hype just to find out what a tool actually does.

I talked about this in AI Hype Has Become Unbearable on YouTube, because the way we present this technology affects whether people want to learn it at all.

Every release can’t change everything

What prompted this was Jev, a newly released model that interested me. It’s built to return structured decisions that software can use directly, rather than generate a text response. You give it context and specific questions, and it returns things like a choice between options or a score, along with probabilities. That makes it interesting for tasks like routing a request to the right place in a workflow. I want to explore where that approach is useful in practice.

I wanted to spend some time with it and potentially make a crash course once I understood it. But the reaction on YouTube, X, and blogs was already turning me off.

When every release changes everything, eventually you stop caring. It becomes the boy who cried wolf. The technology might be worth learning, but you’re rolling your eyes before you even click play.

That also makes it harder for people trying to teach without the hype. I’ve made crash courses on Claude Code, Cursor, and OpenClaw, along with my Blueprint workflow video. Those were straightforward Traversy Media tutorials: showing you how to use something.

Sometimes those videos get lumped in with the exact content I’m frustrated by. People see AI in the title and immediately tune out. I understand the fatigue, but I’d ask people to judge the actual content. There’s a difference between teaching someone a workflow and declaring that their entire career changed this morning.

I’m not anti-AI. I’m tired of the hype around it.

Show me what happens when something needs to change

The launch-day videos often follow the same format. A model comes out, someone gives it a prompt, it builds something in one shot, and we skip to the finished result. Then comes a benchmark and a lot of excitement.

What I want to see is what happens when you need to change something.

Put the tool into an existing project with bugs and decisions made six months ago. Show how it handles the change, where it gets confused, and what you have to do to get the work finished. That’s where I’d actually be using it.

A one-shot demo can be interesting. It just doesn’t tell me enough to judge how useful the tool will be in my own work.

If a model came out an hour ago, you can share your first impressions. But saying it changes everything takes experience and actual use cases. That’s why I don’t rush to teach brand-new technology. I need to use it before I feel comfortable explaining it to someone else.

My OpenClaw crash course came out six months after its release because I needed that time with it. By then, the hype had died down, but I had something useful to teach.

I understand why creators are struggling

I’ve seen people whose work I’ve enjoyed for years get pulled into this style of content. I’ve probably made videos that could be perceived that way myself, so I’m not putting myself on a pedestal.

I also don’t suddenly lose respect for established educators because they’re trying to find their footing. People like Max from Academind, Mosh, and Net Ninja deserve respect for the work they’ve put into helping people learn.

We built learn-to-code platforms from nothing and put our hearts into them. Now the industry is changing, and it can feel like the thing we worked so hard to build is being phased out. I understand why people don’t know where to go next.

The first two years of my YouTube channel, I made absolutely nothing. I did it because I loved it. Even though it eventually became a business, teaching was the reason I started.

I’m still figuring out where I fit into all this, too. I want to keep teaching useful things without feeling like every video needs an exaggerated claim to get someone’s attention.

You don’t have to replace a workflow that works

Social media makes it look like you have to use every new model immediately and rebuild your workflow every week.

If what you’re using works, keep using it.

When something catches your attention, try it on a task you actually need to do. See whether it helps. If it does, add it to your workflow. You don’t need to adopt it just because everyone is talking about it.

Take benchmarks with a grain of salt, too. A model generating some weird game better than another model doesn’t necessarily make it more useful for your projects. What matters is how it performs on the work you need help with.

I don’t want the marketing to turn people off AI altogether. There’s plenty worth exploring. But you can be interested without treating every release as an emergency.

What I want to keep teaching

Using AI well involves more than opening a prompt and saying, “Build me an app.”

There’s context management, skills, subagents, code review, CI/CD, and how you put those things together into a workflow. There’s a lot of technical material to teach.

It’s harder to turn that work into a video than a conventional coding tutorial. When I’ve written the code beforehand, I know what’s going to happen. With AI, there’s waiting, and the results can be unpredictable. I think that’s part of why so much content falls back on quick demos.

But it is possible to teach this stuff properly. I’ve made a 16-hour coding-with-AI course, and the response from people taking it has been encouraging. I want to do more of that kind of work.

I also want to keep teaching coding. I love it, and I still believe people need the fundamentals. The format may change. Shorter, focused tutorials around particular concepts make sense to me, with longer courses for larger projects. You need to understand what you’re building, even if you don’t memorize every bit of syntax.

If I’m excited about a tool, I want to explain why and show where I actually use it. If it falls short, I want to show that, too. There’s enough interesting technology out there without exaggerating what it can do.

With agentic coding, I don't always get that feeling. I can produce more code and still feel less connected to the project.

I don't think that means AI ruined coding. I use it every day. But the way many of us start using it replaces the tight feedback loop that made coding satisfying with a prompt, a wait, a notification, and a context switch.

The workflow deserves a closer look.

Prefer to watch? I walk through these workflows in my video on traditional coding, agentic coding, and flow state.

Why manual coding makes it easier to stay involved

When you write code manually, you move through a fairly tight loop: think, write, run, observe, adjust.

You start with a feature and work through the details. Which files need to change? How does the data move through the application? What should happen when someone submits the form?

Then you write enough code to try it. Maybe it works. Maybe it throws an error. Maybe it technically works but doesn't behave the way you imagined. Whatever happens, you have something to respond to.

Each result gives you something to respond to, keeping the next decision close to the last one.

That loop can repeat dozens of times while you build a feature. As you get into it, you stop consciously moving between planning, coding, and testing. You're just solving the problem in front of you.

Manual coding has plenty of interruptions too. Builds take time, documentation sends you down rabbit holes, and sometimes you're simply stuck. But the work itself keeps asking you to make the next decision.

For me, that involvement has always been part of the reward. Getting a difficult feature working feels good because I experienced the little decisions and breakthroughs that got it there.

What changes when an agent takes over

With an agent, the planning may look similar. You have an idea, a project plan, and a feature to build. Then you describe the feature and hand it off.

Now you wait.

You're probably not going to sit there watching the agent work. You check your email, open another tab, or move to another project. Desktop tools make that especially easy. Project A is running, so you prompt project B. While that's running, you start something in project C.

Eventually, project A finishes. Now you have to remember what you asked for, what you expected, and which parts of the application might be affected. You review the changes, test the result, and find something that needs adjusting.

You send another prompt. While you're doing that, project C finishes.

In the beginning, this can feel like having superpowers. You have several agents working at once, and things that once took days appear in minutes. The amount of output is exciting.

But I've found that it can also leave me scattered. Instead of spending two hours working through one difficult problem, I spend those hours repeatedly remembering where I left off in several different problems.

An illustration of fragmented attention, not measured productivity data. The colored rows represent different projects.

The work is moving, but I'm never fully settled into any of it.

AI coding gives your brain repeated opportunities to leave.

Each project has details you need to keep in your head: the current feature, the relevant files, the unresolved questions, and the decisions that brought you here. Returning to a project means rebuilding enough of that understanding to judge what the agent did.

You reread files. You forget why an approach was chosen. You overlook a change that conflicts with an earlier decision. None of those moments seems like a big deal on its own, but together they can make the whole process tiring.

Your attention also starts following notifications. You switch because an agent finished, rather than because you reached a sensible stopping point.

Bigger handoffs can weaken your understanding

The other thing I notice is a loss of ownership.

That doesn't mean you did nothing because an agent wrote the code. You had the idea, planned the work, directed the agent, and decided whether the result was acceptable. Those are real contributions.

But the bigger the task you hand off, the more decisions arrive without your involvement.

An authentication feature might include choices about the user model, validation, error handling, session management, and how the interface responds. If all of that appears in one large diff, you have a lot to understand before you can confidently accept it.

You can review the result, but you didn't follow how those decisions developed. That difference becomes noticeable when something needs to change. You may know the feature works without knowing where its assumptions live.

One-shotting an entire application takes this further. You can end up with something that looks convincing while leaving you with a codebase you barely understand.

For me, that distance affects both the quality of the work and how satisfying it feels to build.

A workflow that keeps me involved

I don't have a perfect system that will put everyone into a flow state. I'm still figuring this out myself.

But a few changes have helped me stay closer to the code without giving up the useful parts of AI.

Keep each task small enough to understand and review

Instead of asking an agent to build an entire authentication system, I might start with the user model. I review it and check that the fields match what the application needs. Then I ask for the registration endpoint, test it, and review that change before moving on.

Smaller requests create opportunities to understand and redirect the implementation before moving on.

The exact size of a task depends on the project. An experienced developer working in a familiar codebase may be comfortable handing off a complete feature. Someone learning the stack may need smaller steps.

The point is to choose a checkpoint you can meaningfully review. If the result is too large for you to understand the important decisions, the handoff was probably too large.

Notice the difference between "build authentication" and "create the registration endpoint using this user model." The second request connects you to the structure of the software. You're thinking about what the application needs and how the pieces fit together.

That's one reason fundamentals still matter. You need to understand models, routes, endpoints, components, and data flow well enough to ask useful questions and recognize when the implementation is wrong.

Some people will say this defeats the purpose. If the agent can build the entire feature, why break it into smaller requests?

Because generating the most code in the shortest time isn't always my goal. I also want to understand what I'm building and be able to change it myself.

This is the thinking behind AI Blueprint, the open-source AI coding workflow framework I built. It gives the agent a structure for planning and building one feature at a time, with specs, project context, and completed history kept in readable files alongside the code. You can inspect the workflow and adapt it to your own projects.

The AI Blueprint website shows how the workflow fits together. The GitHub repo has the source and setup instructions.

You don't have to use my exact setup. It's one example of putting these ideas into practice; the part that matters is choosing checkpoints that keep you involved.

Stay with the project while the agent works

When the agent starts processing, I try not to automatically jump into something unrelated.

There's usually something useful I can do within the same project. I can read the surrounding code, think through an edge case, prepare a test, or check the current task against the plan.

I don't need to watch every line appear. I just want to keep the problem fresh enough that I can make sense of the result when it arrives.

If I'm waiting on project A, immediately loading project B into my head makes it harder to return. Staying with project A gives me a better chance of keeping some continuity.

Review while the context is fresh

When the agent finishes, I look at the diff and test the behavior before moving on.

Did it solve the problem I asked it to solve? Did it change unrelated files? Does the implementation fit the existing code? Do I understand the decisions well enough to work on it manually?

If something needs adjusting, I'd rather catch it now, while I still remember what I wanted and why.

Letting complicated agent tasks pile up creates another kind of backlog. The code may be written, but I still have to understand and verify it. Leaving that until later doesn't remove the work; it gives me more to reconstruct when I return.

Use parallel agents without following every notification

I'm not against parallel agents. They can be useful when they're investigating related parts of a project or handling work I can review at a planned checkpoint.

The problem is having several unrelated projects compete for my attention throughout the day.

The number of agents matters less than what their work demands from me. Several agents contributing to one clear goal may be manageable. Three agents working on three different applications can leave me constantly switching between unrelated decisions.

I want to choose when I review background work, rather than let every completion notification choose for me.

What I'm trying to preserve

The workflow I'm aiming for feels closer to working with a fast pair programmer. The agent handles a lot of implementation, while I stay involved in the decisions and feedback.

Will that produce as much raw code as opening ten tabs and handing off ten features? Probably not. But the amount of code generated tells me very little about whether I'm building something good.

I care about whether the result works, whether I understand it, and whether I can maintain it without asking an agent to explain my own application every time I return.

I'd also be lying if I said this gives me exactly the same satisfaction as writing code manually. It doesn't. But it feels much better than handing off huge tasks and coming back to a pile of changes.

I know the product better. I can jump in and work on a feature myself because I understand where things are and why they were built that way.

If you've been getting more output from AI while enjoying the work less, try changing the size of the handoff. Pick a checkpoint you can understand, stay with the project while the agent works, and review the result before moving on.

That's the experiment I'm still running: finding how much I can delegate while keeping the involvement that made me enjoy coding in the first place.

Adapted from my video, Traditional Coding vs Agentic Coding: The Flow State Problem. Workflow illustrations are frames from the video. The AI Blueprint screenshot is from its website.

Originally published on Traversy Media.

That shift appears across React, Vue, Angular, Node.js, monorepos, mobile apps, desktop apps, and even the application layer around AI. The real question is no longer whether people use JavaScript. It is where raw JavaScript still fits best and why so many projects now start with TypeScript instead.

I also created a YouTube video on this topic.

TypeScript Has Become the Default Across the Modern Stack

A big part of the answer is scale. GitHub's 2025 Octoverse report says TypeScript became the number-one language on GitHub by monthly contributors, passing both Python and JavaScript. The 2025 State of JavaScript survey found that respondents spent 77% of their JavaScript and TypeScript coding time writing TypeScript.

That does not mean TypeScript replaced JavaScript. GitHub still saw more new JavaScript repositories overall. But the trend is clear: TypeScript has become the normal choice for modern application development, especially once a project grows beyond a tiny script.

React, Vue, Angular, and Node.js Have Made Typed Workflows Feel Standard

The front end is where the shift feels most visible. React supports TypeScript fully, Vue is written in TypeScript and supports it first class, and Angular has used TypeScript classes for components since Angular 2. You can still write regular JavaScript with React or Vue, but a new app created with Vite or another CLI usually comes with TS and TSX files by default.

The back end has moved too. Node.js can run TypeScript files directly by stripping the types and executing JavaScript underneath. That becomes especially useful in a monorepo, where the front end, an API, a background worker, and a shared package all live together. Instead of defining a user, product, or API response in three different places, you define it once and reuse it everywhere.

A few patterns make that appeal especially clear:

1. Shared types reduce duplication across client, server, and worker code.

2. Zod lets you define a schema once, infer TypeScript from it, and validate real data at runtime with the same source of truth.

3. React Native projects now often default to TypeScript for mobile work.

4. Electron templates commonly use TypeScript for desktop apps.

5. Vercel's AI SDK puts TypeScript at the center of AI application code.

Taken together, TypeScript is not just a nicer editor experience. It has become a shared language across a huge part of the application stack.

TypeScript Won Because It Made JavaScript Feel Safer and More Legible

The appeal is not mysterious. TypeScript brought ideas developers already knew from languages such as Java, C, and C++ into the JavaScript world. That mattered when JavaScript still had a reputation as a toy language mostly used for form validation and dropdowns.

The practical benefits are what keep people using it:

• Renaming a shared field, such as changing name to fullName, can instantly reveal every component, API route, or function that still depends on the old field.

• Autocomplete becomes more accurate because the editor understands what a function expects.

• Types act like contracts, helping different pieces of the codebase describe how they fit together.

• Refactors become safer because you can jump to definitions and rename things across a project with more confidence.

There is also less friction than there used to be. Frameworks, libraries, and build tools now support TypeScript extremely well, and its inference has improved enough that you often get strong type checking without annotating everything manually. You can gain better autocomplete, safer refactors, and clearer feedback without turning the project into a ceremony festival.

It's just one more useful layer of feedback.

That matters even more when AI is writing part of the code. An agent can still produce perfectly typed garbage, so TypeScript should never replace tests or code review. It simply provides another check on top of the others.

Learn JavaScript First, Then Add TypeScript When the Project Earns It

Beginners should still learn JavaScript first. If the goal is web development, skipping straight to TypeScript syntax is backwards. Learn functions, objects, arrays, scope, asynchronous JavaScript, the DOM, and how the language behaves at runtime before adding another layer.

That foundation matters because weird TypeScript bugs are usually JavaScript problems in disguise. Once those fundamentals are solid, TypeScript becomes the next step, not the first step. You do not need to become a type-system wizard. You only need to recognize the types you will encounter in real projects and learn how to read the errors.

JavaScript still has real jobs that TypeScript does not always improve. Plain JavaScript can be the better choice when the work is small, quick, or intentionally simple:

1. A tiny script or quick prototype often does not need the extra setup.

2. A low-code project can move faster without types getting in the way.

3. Teaching fundamentals is sometimes easier when the type system is not clouding the lesson.

4. A one-off file that only needs a few lines and a run command can be better left alone.

Choosing JavaScript does not make the work amateurish. It means the tradeoff makes sense. TypeScript adds value, but it also adds concepts, configuration, and another class of errors to understand. Use JavaScript when simplicity wins, and reach for TypeScript when the project has enough moving parts to deserve the extra structure.

JavaScript still powers the web, but TypeScript now shapes how a huge part of the ecosystem gets built. The smartest choice is not picking a side. It is knowing when the typed version earns its keep.

This article was adapted from Does Anyone Use JavaScript Anymore?.