DEV Community: Marco Chavez

AI: The Given and the Gotten

Marco Chavez — Wed, 22 Apr 2026 07:09:17 +0000

We fear AI. What it will take from us. It will take our jobs, knowledge, and problem-solving abilities away from us. We work tirelessly to understand what AI will give to us, and what AI will have gotten from us.

Agentic AI, objectively, is a multiplier in both the positive and negative sense.

A multiplier cuts both ways. Poor practices implemented 10x faster means we see rapid degradation. Good practices implemented 10x faster means we have room to refine them, measure them, and grow into better ones with increasing accuracy. Same tool, opposite outcomes. The difference is what we choose to multiply.

The Mechanic

If you take a mechanic and ask him to perform a job with rudimentary tools, he can perform the job as-needed. If you give that same mechanic better tools, someone to bounce ideas off of, and the chance to plan their work a little bit better, output speeds up and the quality slightly increases. If that same mechanic becomes lazy and begins handing off all their tasks to their person, and doesn't take care of their new tools, and decides that planning is taking too long, their quality severely decreases but their output speed remains the same.

The Formula

I'd like to think that this can be simplified to an explainable formula. This phenomenon is explained in our industry as "Automation Bias" or "Agentic Decay."

The Variables

To model this, we need to define the core variables that govern an agent's behavior:

C_base = Core Capability. The base intelligence of the underlying model/person.
T = Tool Integrity. The quality, precision, and maintenance of the tools available.
P = Planning Depth. The effort spent on reasoning before acting.
D = Delegation Rate. How often the agent hands off tasks to external tools or sub-agents instead of doing the work natively.
V = Verification. The oversight or evaluation applied to the tool's output before finalizing the response. Self-correction loops, human-in-the-loop.

The formula that determines the quality of output then becomes:

Q = C + (P * T) - D(1 - V)

The Bonus: Good tools multiplied by good planning (P * T) elevates the output far beyond the base capability.

The Trap: If verification drops to zero (V = 0), the delegation penalty completely subtracts from the agent's baseline. It relies heavily on tools it is no longer checking, resulting in fast but severely degraded output.

The Human Condition

The one thing that AI lacks. Our accumulated experience could never become useful to have in AI. Humans will never benefit from having an LLM that has experienced humanity. This is why AI companies spend so much time developing "tools." That's why AI companies also don't share their tools. It's why developers express among each other that Claude Code has better "tool calling" than Codex does. Finally, that's also why us Windows users keep getting complaints from our AI agents that we don't have rg installed.

We benefit most from having an AI agent because of its ability to compute. Data centers are trying to solve the problem of being able to keep up with compute power, while we are all working on trying to have AI do more and more computing for us. That inhuman ability to quickly recognize patterns and process information is what is most desirable about our AI assistants.

This means that the driver needs to be human. If there is no reason for AI to be human, then there is 100% the need for AI to work with and for humans.

The Archi-tech-t (get it)

If the human has additional computational power, their ability to be creative in their solution is expanded. The potential for better design has increased. Our planning depth has grown. Most people don't recognize that their code solutions drive them away from the creative part of completing a task.

Think about the last time you sat down to solve a problem and immediately started typing. You skipped the part where you sketch it out, argue with yourself about the approach, or wonder if the problem you're solving is even the right one. The typing felt like progress, but most of it was translation work. Syntax. Boilerplate. The stuff a compiler used to complain about.

That's the part the AI is good at. Which means the part that was left — the part that was always the actual job — is the architecture. The design. The why before the how. Hand off the translation and suddenly there's room to think again.

The architect was always the role. We just didn't have time for it.

Asleep at the Wheel

Bring back D(1 - V).

If humans are the drivers, what happens when we suffer from automation bias on a societal scale? Easy. We become the lazy mechanic. Not the agent. Us. We stop checking the tools. We stop planning. We accept the output because it came back fast, and fast feels like progress.

The penalty in the formula stops being about the AI at that point. It's about us. V drops to zero on the human side of the equation and the delegation penalty starts eating our baseline instead of the agent's.

Here's the thing though: we're never going to win a compute race against a data center. We shouldn't want to. Our job isn't to compete with the machine. It's to stay awake at the wheel, keep the tools sharp, and actually read what comes back.

The Empath

If AI handles the compute, the valuable human skills become the ones AI can't compute.

Empathy. Edge-case intuition. Understanding what the end user is actually trying to do versus what they asked for. Knowing when a technically-correct answer is the wrong answer because the person on the other end is tired, frustrated, or working around a constraint they forgot to mention.

That's the shift. The talent in the industry is separating: computation on one side, and being human, creative, and thoughtful on the other. Both still matter, but they're no longer the same job. The next frontier isn't writing better code. It's writing better human-to-human solutions, with AI as the lever.

Point the compute at the right problem, and the rest is a very human job.

Don't Over - React about frameworks/libraries

Marco Chavez — Thu, 07 May 2020 19:47:39 +0000

I know many of you are probably trying to determine whether or not to use Angular, Vue, or React in your current projects. Have you considered not using them?

Do not feel pressure of deciding what to use

I am almost entirely sure 80% of beginners fall into tutorial hell (I did too). Where you don't know what to get better at because you don't know what companies are looking for and you don't value what skills you have. I personally feel like a lot of this fear comes from not understanding enough of the basics.

Do not become comfortable with what you know about the basics

You will never understand everything. But what helps you become better at understanding complex concepts is to keep hitting the books, videos, or livestreams (whatever your poison is) on the basics. If you do not understand JavaScript itself don't skip it to learn a framework. Take that ES6/ES7 course because I promise you that if you understand that first, it won't be so hard figuring out how to start on your next project.

Just recently I went back through FreeCodeCamp's material and learned a bunch from revisiting the basics. For example: I always use a theming framework for my grids but stopped using them since they showed me how to use CSS's new grid system.

I also found a ton of value in taking short Udemy courses like this one.
JavaScript, ES6, ES7, ES8, and beyond
which shows you all the latest and greatest features of JavaScript.

Another great course would be JavaScript, understanding the weird parts which took my understanding to a whole other level.

There are a ton of resources out there, but please (at least once a month) go back to the beginning. You will 100% feel more confident in yourself once you explain what a call stack is, or what lexical scope is. Once you understand the basics everything else just falls into place.

You can find my social media profiles on my profile here, please feel free to reach out if you need help finding the right material to guide your learning!

So you're ready to start a project? Advice for beginners success.

Marco Chavez — Wed, 23 Oct 2019 17:51:04 +0000

You're getting ready to build your app

You woke that morning with a fresh idea in your head, and your convinced you're going to make something that is going to change your life forever. You had a big breakfast, you watched a videos of a cats playing the piano, and you finally have your computer setup. After you've setup your HTML document you question yourself about how the structure of your website should be. And after you lay some of your HTML out, you start editing your CSS.

This is where you can hurt your project

This is how a lot of my days went before I got a good grip on how to approach projects. Most of the time I would work on one part of the application and only complete part of it before moving onto the next part without any clear goals. I would write some HTML, then switch the CSS and began styling the tags I've added. What I didn't think about at the time was that every time I added a new tag I needed to re-style everything I have already stylized because things didn't always work separately as they would normally work together. This would also bum me out while I was working on projects. Since I would constantly have to go back and fix stuff I had already worked on I didn't feel confident in my code.

How did I get better?

It had a lot to do with practice. One of the first things that made me feel more confident about my code was seeing the huge changes I could make to my completed HTML after working with the CSS for fifteen minutes. I also stopped caring about how much CSS I was using. I followed along to a lot of youtube videos and people can do some really awesome things with just a couple of lines of CSS, and even though that's ideal - it all depends on how you want your project to look. I focused way too much on the semantics of my code before I just got into the functionality of it. Don't worry about optimization until after you have completed your code. You will slowly get better at on-demand optimization after you've worked on 3-4 completed projects. I also stopped trying to be as great as everyone else.

Stop trying to be just another developer

Just because certain things take you longer then other people, and it may take you more code to complete something that someone else can do with less - that doesn't mean that you aren't great. One thing I noticed while getting confident in my code was that I had to ween off of those videos where you follow along. I apologize to those who depend on those videos and make them but in my one hundred percent honest opinion you only learn 5% of what the goal of the video is. This is because you're watching someone who uses the quick and easy way to accomplish something and you start using things you can't understand entirely. Don't let yourself use black boxes because there's nothing more frustrating then not understanding what you're doing, especially when you have to go back and debug some errors later. You should only watch follow along videos if you already understand the concept, but you need a refresher on how to use it. If you need to learn something new and you do need to watch a youtube video on it, I would highly recommend you take the time to read the documentation or pay for a Udemy course on whatever it is you need to learn. Mozilla has my favorite documentation because it actually offers guides to follow along with.

Watching Youtube videos should come after attempting to understand the documentation.

I know all of this sounds difficult

But I promise you, in order to be a great developer you have to make some big sacrifices. It won't be easy, and we have all been there before. You just have to trust yourself, and always ask for help! There are plenty of people like me who would love to hear from you whether it be on this platform or another like Stack Overflow. You have the entire internet at your disposal, and an army of others who have been in your shoes. So make that cup of coffee, fill it with creamer and sugar, and type out the best program you can.

You Are One Awesome Programmer!

You Should Know 'This'

Marco Chavez — Thu, 03 Oct 2019 20:48:01 +0000

What is 'This'?

First of all, as the MDN docs will tell you

this keyword behaves a little differently in JavaScript compared to other languages

this allows you to bind a property to the the object that you are writing your code in. So if you are assigning the value of Hello World to this.helloWorld, you give yourself the ability to reference that property from the name of the object with the dot operator. If you assign a value to a property with this to the window (for web) or for the global (for node js) objects you can access them with the window.OBJECT or global.OBJECT.

In React we constantly use this to assign properties on a class to the scope so the object will be available to all functions and properties in the class.

this also allows you to use similar naming conventions when declaring variables within an object. The following is an example.

function scope(first, last) {
  this.first = first;
  this.last = last;

  console.log(this.first + " " + this.last);
}

scope("Marco", "Chavez");

result of the example

Marco Chavez

in the console.

Why do you use 'this' with React?

By default, we cannot access properties, state and methods within the components from the event handlers used in our render methods. I will use methods for example (since this is what I have to bind more often then anything else). In order to use a method within your component for an event handler in your JSX you have to bind the method in either your constructor, or the event handler itself.
It would look something like below.

<input onChange={this.METHOD.bind(this)} />

or you could bind it in the constructor (which is much easier to remember)

constructor(props) {
    super(props);

    this.METHOD = this.METHOD.bind(this);
}

render() {
    return <input onChange={this.METHOD} />
}

I typically bind it in the constructor so I don't have to remember later in the render method to bind it to this. Either way, binding allows you to use component methods in your event handlers because the event handler has its contents bound to the component's instance. I know that last sentence was sort of confusing, but what you should take out of it is that the property becomes a part of the component you are using when you bind it.

Here is some of my info

I want to thank you for taking the time to read this article. I am also very happy that you are taking the time to become a better developer yourself. I highly encourage that you join this platform and start writing yourself, since there is no better way to completely understand something until you are able to teach it. This is my first article, and I want to prepare you for a whole lot of React and Express articles, since that's what I work with the most. This was MarCode, have a great day!

The image in the header was created by Value Coders