DEV Community: Brad Traversy

12 Important Concepts All Software Developers Should Know

Brad Traversy — Wed, 23 Sep 2026 13:08:08 +0000

Artificial intelligence (AI) is changing what it means to spend a day developing software. Less time goes into typing code, and more goes into planning, reading, reviewing, and testing it. But writing less code doesn't mean you can afford to understand less of it.

Prefer to watch? Here’s the video version on YouTube.

I think reading code is becoming one of the most important development skills. When an agent hands you a feature spread across several files, the real question isn't whether it looks convincing. It's whether you understand what it does, what data it touches, and why those changes belong in your project.

Understanding code matters more than memorizing it

Functions, loops, conditionals, and data types are still essential. Without those fundamentals, you're going to struggle to follow what an AI tool generates, much less judge whether it's right. What's becoming less useful is trying to memorize every method in a language or every option in a framework. Most developers were looking that stuff up anyway.

The useful shift is from remembering syntax to understanding behavior. You need to recognize what a function expects, trace what happens after a user clicks a button, and notice when a seemingly small change reaches into unrelated parts of the application. Those abilities help you direct an agent instead of just accepting its output.

That doesn't mean you need to master software architecture before touching AI. These are concepts to keep learning while you build. Each one gives you another way to inspect generated code, ask better questions, and catch problems before they turn into a debugging marathon.

These 12 concepts give you a practical review checklist

The concepts connect to one another, but they answer different questions. The first three explain how a program moves through work. The next three explain what its pieces can access and change. Abstraction, modularity, and architecture describe its organization, while the final three make you look beyond a single, successful execution.

1. Control flow tells you what actually runs

Control flow is the order in which your code executes. What happens first? What happens next? Which path runs when a condition is true, and which path runs when it isn't? Conditionals, loops, and exception-handling blocks all shape that path.

AI can generate code that looks clean while getting the sequence wrong. A function might return too early, skip validation, or handle an error somewhere that doesn't actually cover the failing operation. None of those problems necessarily makes the code look messy.

When reviewing a change, follow the execution rather than scanning for familiar syntax. Walk through the successful path, then take the alternate branches. If you can't explain how execution reaches a particular operation, you don't yet understand whether that operation is safe or even reachable.

Validation determines which branch runs. Invalid input stops before the save operation.

2. Data flow connects a feature across files

Data flow describes where information comes from, where it goes, and how it changes along the way. A common web application flow begins with a user filling out a form. That data travels through an application programming interface (API), reaches a database, returns as JSON (JavaScript Object Notation), and appears in the user interface (UI).

That's one feature, but it may involve several files and several transformations. Looking at each file separately can hide the connection between what the user entered and what the application ultimately displays.

Trace a meaningful value all the way through. What did the form submit? What did the server receive? What was stored, and what came back? When AI generates multiple files at once, following that journey helps turn a pile of changes into a feature you can actually understand.

Follow the data from the form to the API and database, then back to the interface.

3. Error flow reveals what happens off the happy path

Error flow is what happens when something goes wrong. A request fails, a required value is missing, a user submits bad data, or a database query throws an error. Real applications have to handle these situations, not just the version where every dependency behaves perfectly.

This is a recurring weakness in generated code: the happy path works, but an unexpected condition makes everything fall apart. A feature can look finished during a quick test while still leaving users stuck when a request fails.

For each likely failure point, ask where the error goes next. Does something catch it? Does the interface stop showing a loading state? Does the user or developer receive a useful message? Knowing that an exception exists isn't enough. You need to understand how the application responds to it.

4. Scope determines where values are available

Scope describes where variables, functions, and other values can be accessed. If a variable is created inside a function, you generally can't use it outside that function. The value belongs to a particular context, not automatically to the entire program.

This matters when AI introduces a value in one place and tries to use it somewhere else. It also matters during refactoring. Moving a block of code can break it because something it previously had access to is no longer available.

When a value appears in generated code, ask where it was created and where it can be accessed. Also check who can change it. Those questions help you distinguish a genuinely available dependency from an assumption that only worked in the code's original location.

5. Input and output define what a piece of code promises

Most useful pieces of code take something in and produce something. A function might accept a user identifier and return a user record. An endpoint might accept form data and return a success message. A component might receive properties and render part of the interface.

The basic review question is simple: What does this need, and what does it produce? That gives you a concrete way to evaluate a function without getting distracted by how polished its implementation looks.

Check whether the caller supplies the arguments the function expects. Then check whether the returned data matches what the next piece of code needs. AI-generated pieces can each seem reasonable in isolation while disagreeing at the boundary. Understanding inputs and outputs lets you spot that mismatch.

Check the inputs a function expects and the output its caller receives.

6. State explains what changes over time

State is data that changes as the application runs. It includes the logged-in user, a shopping cart, form values, a loading status, and information stored in a database. It's the application's changing picture of what's happening.

A lot of bugs appear when that picture stops matching reality. AI might put state in the wrong place, duplicate it, or update one representation while forgetting another. The result is an application that behaves as if something is true when it no longer is.

Pay attention to where state lives, who can update it, and what should react when it changes. Don't stop at finding the assignment that updates a value. Follow the consequences: which parts of the application depend on that value, and will they now reflect the same situation?

The quantity changes to two. The badge must reflect the same state instead of keeping its old value.

7. Abstraction should hide complexity, not hide the explanation

Abstraction puts complicated work behind something simpler to use. A user-creation function might validate input, hash a password, save a database record, and return the new user. The calling code doesn't need to repeat all those operations every time it creates an account.

AI creates abstractions constantly: helpers, services, hooks, middleware, and utilities. Good abstractions make behavior easier to use and reuse. Bad ones make you jump through five files just to understand a straightforward operation.

There's a balance here. Too little abstraction leaves repeated complexity everywhere. Too much adds layers that don't earn their place. When an agent introduces a helper or service, ask what complexity it removes and whether the resulting code is genuinely easier to follow. A new file isn't automatically an improvement.

One clear interface can coordinate several implementation steps.

8. Modularity gives each piece a clear job

Once you've separated logic into pieces, modularity asks where those pieces should live and what each should own. Real projects usually need more organization than one massive file, but splitting code randomly doesn't solve the problem either.

A typical application separates responsibilities along these lines:

Routes handle incoming requests.
Controllers or handlers decide what happens next.
Models deal with data.
Components handle the user interface.
Utilities contain reusable helper logic.

The point isn't to force every project into exactly that arrangement. It's to give each piece a recognizable job. That makes a codebase easier to navigate, review, and work on with other people.

For AI-assisted development, modularity helps you notice misplaced logic. A feature may work while putting a responsibility somewhere that will make the next change harder. Review where the code landed, not just whether it runs.

Give each module a clear responsibility.

9. Architecture gives you the map for directing an agent

Architecture is the application's overall structure. Where does the front end live? Where is the back end? How does the database fit in? How do those parts communicate, and which parts own which responsibilities?

You don't need to be a software architect to understand the basic shape of what you're building. But you do need that map to point AI in the right direction. Adding an endpoint and changing how information appears on screen are different requests, even when they contribute to the same feature.

Abstraction simplifies a piece of logic. Modularity organizes the pieces. Architecture explains how the whole application fits together. I think these are especially important because AI can solve an immediate problem without protecting the project's long-term structure. It may duplicate an existing capability, introduce an unnecessary layer, or put otherwise valid logic in the wrong place.

A typical web application separates its interface, server logic, and stored data.

10. Side effects make a function bigger than its return value

A side effect occurs when code changes something outside itself. Updating a database, writing a file, sending an email, and modifying state all count. Returning a value is only part of what such a function does.

A pure function, by contrast, calculates its result from its inputs without changing the world around it. That makes its behavior easier to reason about. You can focus on what goes in and what comes out without also tracing external changes.

AI often mixes calculation and side effects together. When reviewing a function, don't assume its return value tells the whole story. Ask whether it merely computes something or also changes something elsewhere. Those hidden consequences are often where surprising behavior starts, especially when another part of the application depends on what changed.

Look beyond the return value for changes to state, files, databases, or other systems.

11. The request-response cycle makes web frameworks less mysterious

In a web application, a user action can cause the browser to send a request. The server receives it, runs some code, perhaps talks to a database, and sends a response back. Understanding that cycle gives you a foundation for understanding a huge amount of web development.

Frameworks such as Express, Laravel, Django, and Rails differ in syntax and conventions, but much of their work follows this same pattern: receive a request, do some work, and return a response. Learning the pattern makes unfamiliar framework code less intimidating.

This also connects to HTTP (Hypertext Transfer Protocol) methods and status codes, along with REST (Representational State Transfer) APIs. When AI generates endpoint code, understand what request it accepts, what work happens on the server, and what the response communicates. Otherwise, you're reviewing only the middle of the interaction.

The browser makes a request, the server does the work, and the response updates the interface.

12. Concurrency makes timing part of correctness

Concurrency means multiple activities happen during overlapping periods of time. Several requests may be running, users may be editing data simultaneously, or background jobs may be processing while the interface refreshes. Software doesn't always move through one neat line of work.

I ran into this with VidPipe, a project that converts videos into articles. Its queue could have one job processing, another waiting, another failing, and another finishing just as the interface tried to update. I spent a week working through an issue around that behavior.

That's what makes concurrency tricky: code can work once and fail when operations overlap. You don't need to become an expert immediately, but you do need to ask what happens when timing gets messy. A successful run proves that one sequence worked. It doesn't prove that every overlapping sequence will.

Overlapping jobs can complete in a different order from the one in which they started.

A serious AI workflow keeps the decisions with you

The difference between agentic coding and blindly accepting generated code isn't simply which tool you use. It's whether you can evaluate the decisions that tool makes. Asking for a feature and hoping the result doesn't break anything leaves the most important judgment unmade.

A more deliberate workflow lets you say, "This logic belongs in a service, not a component," or, "This helper is unnecessary because we already have one." You can trace data, challenge a state update, and ask what happens when a request fails or two jobs finish together. Those are concrete interventions, not vague requests to make the code better.

You don't have to master all twelve concepts before building with AI. I certainly haven't mastered every corner of them. Keep learning them through the code you're already reading, testing, and debugging. The better you understand the application's behavior and structure, the better you can prompt, review, and direct the agent.

AI can write the feature; you still have to know whether it belongs in your codebase.

This article was adapted from 12 Important Concepts In the Age of AI Software Development

AI Hype Has Become Unbearable

Brad Traversy — Tue, 22 Sep 2026 10:16:49 +0000

If I see another thumbnail saying “This changes everything” an hour after a new AI model comes out, I’m going to lose it.

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.

Traditional Coding vs Agentic Coding: The Flow State Problem

Brad Traversy — Sun, 20 Sep 2026 14:19:20 +0000

One of the things I've always enjoyed about coding is getting completely locked into a problem. You know what you're building, each small obstacle leads to the next decision, and you stop noticing how much time has passed.

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.

I've Changed My Opinion On Vibe Coding

Brad Traversy — Mon, 18 May 2026 15:35:01 +0000

As I said in this video, I used to be pretty skeptical of vibe coding. Watching people ship apps without understanding a single line of what was generated always felt like a disaster waiting to happen, especially when beginners hit the first real bug and have no idea where to start. And the idea that you can build successful software or SaaS without learning software development? I never bought that for a second.

That said, my opinion has shifted a bit. The models are better, I've been using Claude Code, GPT-5.5, and OpenClaw in a much more serious way, and I've seen firsthand where AI can actually carry real weight. The catch is that it only works when you already understand what you're doing.

Vibe coding is the extreme end of the AI coding spectrum

There's a real spectrum when it comes to coding with AI. On one end, you have one-shot prompting with platforms like Lovable. On the other, you have autocomplete in VS Code. Somewhere in the middle is the sweet spot: let the agent write the code, but you still make the architectural decisions, write the specs, and test the result.

That middle ground is what I actually teach in my AI course, and it's a lot different from what I mean by vibe coding.

Vibe coding, to me, is when you're barely looking at the code at all. You're going off the vibes instead of the syntax, and for a long time I was totally against that. I still think a lot of people confuse "using AI" with "understanding software," and those are not the same thing.

Better models changed the equation, not the rules

A big part of why I've softened is simple: the models are just better now. Claude Opus 4.7 with Claude Code, GPT-5.5 with Codex, and even OpenClaw with GPT-5.5 are all good enough that, if you know how to direct them, they can do a lot of the heavy lifting.

I'm seeing less hallucination, more first-try success, and a lot less need to babysit every line the way I would have with something like GPT-5.3. That matters.

But the model getting better is only half the story. The other half is that I've learned how to work with these systems more effectively. I know how to manage context and memory, how to map out documentation and spec files, and how to steer the model toward the outcome I want.

That's exactly why I'm not willing to pretend the tool alone is enough. Better output does not erase the need for actual judgment.

Foundation still decides who can use AI well

I'm not budging on this part: vibe coding is not okay under any circumstance if you do not have a foundation in software development and architecture. If you do not understand the basics, AI does not magically create them for you.

A few things make up that foundation:

How the web actually works

You need to understand requests, responses, status codes, and what happens between the browser and the server. Without that, you're just guessing at what the app is doing.

How data is structured

You need to understand how to model data, how relationships work, and what an index is. If the data model is fuzzy, the app will be fuzzy too.

How to read code, not just write it

You need enough hand-written code under your belt that you can read code and actually see what it's doing, instead of skimming past it like noise.

How debugging feels in real life

You need to have been burned by enough bugs to recognize bad patterns. That kind of pattern recognition does not come from prompting.

You do not need a CS degree. You do not need to memorize sorting algorithms. You do not need to be a genius. But you do need to have built things from scratch, broken them, fixed them, and learned what failure looks like.

That confidence is the dangerous part.

Beginners should use AI to learn faster, not skip learning

I am not saying beginners should stop using AI tools. That ship has sailed, and fighting it is the wrong move. The better move is to change what you use them for.

Use AI to accelerate learning, not to bypass it.

There's a huge difference between those two things, and that difference is where most people go wrong. If you're new, let the model explain the code it generates. Type it out yourself. Break it on purpose. Then figure out why it broke.

That process is where the actual growth happens, and it's also why the developers who will do well over the next few years are not just the ones who can prompt well. They're the ones who can prompt well, read code, design systems, and debug under pressure.

The AI handles the typing. You still have to handle the thinking.

Vibe coding works best after you've earned the right to trust it

Once you're past the learning stage, vibe away. Seriously. If you already have the foundation, AI can be an incredible force multiplier, and I've been using it that way in my own workflow and in my home lab with eight machines managed by OpenClaw.

But it should not become your entire workflow for every project. If you rely on it for everything, you will forget too much and become too dependent on it. That's where the trouble starts.

My position now is simpler than my old one. I am not against vibe coding anymore. I just think it should be a tool, not the whole system.

The AI handles the typing. You still have to handle the thinking.

And that is the whole line between useful and dangerous: let Claude, GPT-5.5, and the rest speed you up, but never let them replace the part of the job that actually makes you a developer.

This article was adapted from I've Changed My Opinion On Vibe Coding

I Built DevSheets.io - A Modern Cheat Sheet Site for Developers (And Why We Still Need Them)

Brad Traversy — Mon, 13 Oct 2025 11:37:53 +0000

We've all been there. You're deep in a coding session, need to remember that one Git command, or the syntax for a CSS flexbox property. You Google it, click the first result, and... ads everywhere. Outdated information. Slow loading. Ten paragraphs before getting to the actual answer.

That's why I built DevSheets.io - a modern, fast, and clean cheat sheet platform designed the way developers actually work.

The Problem with Existing Cheat Sheets

Don't get me wrong - there are some great resources out there. But many suffer from:

Information overload without structure - Everything on one massive scrollable page
Outdated content - Still showing jQuery examples in 2025
Terrible UX - Intrusive ads, slow loading, poor mobile experience
No search - Finding specific commands means Ctrl+F through walls of text

I wanted something that felt native to how we actually code - quick, focused, and just works. I have been creating educational content on web dev and other tech topics for years and I have taken the stuff that people often struggle with, and put it into short, concise sheets that are easy to understand.

It does not cost a dime and there are not even any advertisements. It is completely free to view all 50+ sheets.

What Makes DevSheets Different

1. Clean, Focused Design

Each cheat sheet is organized logically with a clear table of contents. No distractions, no ads. Just the information you need.

2. Modern Tech Coverage

We focus on technologies developers actually use in 2025:

React Router v7 (with the new Library and Framework modes)
TanStack Query for server state management
Docker commands and orchestration
Modern JavaScript patterns (async/await, modules, etc.)

3. Estimated Read Time & Difficulty

Every sheet shows how long it'll take to reference and the complexity level. Planning to learn TypeScript? You'll know it's a 10-minute intermediate-level reference before you dive in.

4. Built for Speed

The entire site is optimized for performance. No bloat, instant navigation, works great on mobile when you're pair programming and need a quick reference.

The Stack

For the tech-curious, here's what powers DevSheets:

Frontend: React 19, Next.js 15, TypeScript
Backend & DB - Next.js, Prisma, PostgreSQL (Neon)
Styling: Clean, responsive CSS with Tailwind CSS
DevOps - Vercel, Github Actions
Content: Structured data that's easy to update and maintain
Icons: Custom SVG icons for each technology as well as Heroicons

I'm also considering:

Dark mode toggle (because of course)
Downloadable PDFs for offline reference
Community contributions for niche technologies
Interactive examples for certain concepts

Why I'm Sharing This

I built DevSheets because I needed it myself. The best tools often come from scratching your own itch.

But here's the thing - I want your feedback. What cheat sheets are you missing? What could be better organized? What technologies should I add next?

Check it out at devsheets.io and let me know what you think in the comments.

For Fellow Builders

If you're thinking about creating a developer tool or resource:

Start with your own pain point - If you need it, others probably do too
Keep it simple - Don't over-engineer v1
Make it fast - Developers have zero patience for slow sites
Get feedback early - Build in public, share often

The web is full of resources, but there's always room for something done better, faster, or with more care for the user experience.

What cheat sheets do you find yourself referencing most often? Drop a comment below!

🔗 Visit DevSheets.io