Lately we’ve found an easy way around that resistance. We no longer need to try over and over to reach the solution, or review the solution in detail to see what we’re missing; language models take care of lightening that challenge. What the calculator once was, an agent is now, with the difference that the calculator did the math, but the reasoning was still ours. The agent promises to do both.

We have feared that technology would affect our intelligence ever since tools have existed. And I don’t want us to fear agents. On the contrary, used the right way they can speed up learning. AI took away the friction that used to come free with learning. Now we have to seek it out on purpose. The good news is that AI itself can help us, if we ask it for questions instead of answers.

The value of mistakes

Learning happens in the struggle to solve a problem, getting it wrong and trying again. Our brain predicts and looks for patterns by instinct. It does so with fast thinking, the intuitive kind, the kind that doesn’t ask permission. To activate slow thinking, the deliberate kind, we need to stop assuming our model is the right one. Get it wrong. This forces us to stop and think seriously.

This has a name: desirable difficulties. They make studying slower and more uncomfortable, but what we learn lasts longer. Something similar happens with what we generate ourselves. We remember it better than what we only read, even if our first attempt is wrong. Mind you, afterwards you have to check the correct answer. Otherwise, the mistake stays with us.

Beware of the illusion of competence. We read something, understand it effortlessly and think we already know it. Until the test comes and we can’t explain it. Rereading your notes feels productive, but almost never is.

In practice, this translates into three habits:

1. Get it wrong first. Before starting a topic, a class or a tutorial, try to answer without knowing. You’ll fail, and that’s what gives the theory the weight of an alarm bell.
2. Don’t reread, explain. After reading, close the material and explain what you understood in your own words, out loud, like you’d explain it to a five-year-old. Wherever you get stuck is the path to follow.
3. Answer before looking. When you test yourself, always write down what you think the answer is before seeing the correct one.

Learning should feel clumsy. Clumsier than doing it with your feet.

Using AI to learn

These practices take discipline, and discipline is hard when the answer is one message away. While AI can be what blocks us, it can also be the answer. An AI that answers takes the effort away from us, whereas an AI that asks gives it back.

We can learn from many sources or from a single tutor. Many sources give more perspectives, but they scatter our attention and force us to find material, organize it and verify it. An AI tutor can gather those perspectives and hand them to us in one place. That way the friction leaves the logistics of studying and stays where it belongs: in the moment of learning.

A cycle that works:

1. Diagnosis. Ask the agent to quiz you until it finds where what you know ends.
2. Material. With that, have it generate study material adjusted to your level: not so easy that you get bored, not so hard that you give up.
3. Test. Have it test you, and you answer before seeing the solution.
4. Repeat. If you fail, go back to the material. If you get it right, move on to the next topic.

This way we can use an agent as a private tutor and aim the difficulty at the right spot.

Closing

For centuries, learning hurt without anyone asking for it. Now the effort is optional and, like almost everything optional, it’s very easy to skip.

AI can give us all the answers. The hard part is asking it for the questions. So the next time you open a chat to understand something, do the counterintuitive thing: ask it to test you, get it wrong with confidence and explain the topic to it as if it were a five-year-old.

Let’s not outsource our critical thinking. And if learning feels clumsy, you’re doing fine.

Even so, the path to landing your first job still has the same steps as when I started. What changed is how you get evaluated.

How I got started

When I started, web development seemed like the safest option. I learned React and Node.js, because using the same language on the frontend and the backend made sense to me. I built the classic to-do lists and, since freeCodeCamp was all the rage, I jumped into the “365 days of code” challenge. There I put together a simple online store with HTML, CSS and JavaScript. It was pretty basic, but it helped me understand how the web works.

Back then I read a lot about how to get a job, and the advice was always the same:

1. Apply to everything you can.
2. Go to meetups and events to meet people.
3. Build projects that show what you know.

I was doing two out of three. I applied like crazy and practiced with React nonstop on side projects.

In the end the job showed up on my university’s Slack. Someone posted that they needed a Meteor developer, a framework that joined the backend and the frontend through methods. First came a technical test, and that’s where the projects paid off: it went well, I moved on to the interview and they saw that I was excited about the technology. I had never heard of Meteor, but knowing the fundamentals it wasn’t hard to adapt. It was just a matter of knowing how to write JavaScript. But this was more than 5 years ago.

What didn’t change

Today it’s still the same: you apply a lot and get rejected a lot. And having someone who recommends you is still what helps the most for the first job.

But something did change. I have classmates with six years of university who still can’t find a decent job in Chile, and it’s not because they don’t know their stuff.

What did change

When you apply, the first thing that checks your CV is how many years of experience you have with each technology. An ATS or a person. If the posting asks for three years of React and you don’t have them, you’re out. The problem is obvious: a junior has no years of experience, because nobody has given them their first job.

I don’t think it’s the recruiters’ fault. Finding out whether someone codes well takes time, so people filter by what’s easy to check: keywords and years. That leaves out precisely the people who are just starting. And with so many companies betting on AI instead of hiring, there’s even less room.

I think this will get better at some point. In the meantime, it makes sense to adjust how we present ourselves.

What I would do differently today

Tailor your CV to each posting. Your CV doesn’t have to tell everything you are. It has to get past the filter. Use the same words the posting uses and leave the rest for the interview. Sometimes I’ve even seen the recruiters themselves edit your CV so that it includes the technologies.

Prioritize referrals. If someone at the company recommends you, your CV goes straight to a person who understands what you do, without going through the years-of-experience filter. That’s why it’s worth investing time in getting to know people in the industry.

Build projects to learn, not to show off. Most likely nobody will look at your projects before calling you, so don’t stress about having a perfect profile. Projects are for learning and for walking into the technical interview relaxed, which is where someone who actually knows programming finally evaluates you. If you understand the fundamentals well, you can hold your own even if the posting asks for a technology you haven’t used.

To wrap up

The process is broken and we’re not going to fix it ourselves. What we can do is understand how it works and not take every rejection personally. Almost always it says more about the filter than about you.

Tailor your CV, find someone to recommend you and keep learning with your projects. There will be rejections and uncertainty, but that’s part of the process, not a sign that you’re not cut out for this.

Every day that passes, AI is more capable. I see how code agents are pushing junior developers out of the equation. In graphic design, generative tools package logos and illustrations in seconds, making the work evaporate slowly but surely. It’s a shadow relentlessly spreading over marketing, audiovisual production and, needless to say, translation.

But there’s a gap that still hasn’t been filled. We’re building systems that can understand language but not the purpose or value of what they say, at least not in a human way. Artificial Intelligence doesn’t achieve the perspective of will, and it can’t deal with the unknown except by hallucinating.

The illusion of will

In case you didn’t know yet, what we call AI these days is LLMs (large language models), systems that learned language patterns by reading an enormous amount of text. At an atomic level it started with the idea of predicting the next word.

Roses are …

Now, predicting the next word requires building a complex representation of the context. Building multiple contexts and relating them to each other in sophisticated ways. How this new word influences the whole conversation. Over time these models have grown in size, and so have their training sets, reaching capabilities that resemble reasoning, communication and problem solving.

And with that came people’s fear and anxiety. But these models don’t cover important aspects of our infrastructure as a society. Not all of our activities can be extrapolated into a training set.

Visualizing patterns, applying probabilities, finding sequences of tokens or words and statistical association is how models see the world. Experience, intent, responsibility, context and values are left to our side of the court.

Because every model categorically confuses frequency with truth, we forget that every dataset it is trained on has errors. That these models touched the internet. And the internet lies, right? Condemned to replicate and optimize the world as we describe it to them. With all the garbage and fiction, all the fanfiction, wattpad and absurd conspiracies. We have to tell the truth apart from the garbage it hands us and connect the wires to get on the right track, our track.

We went to A and then C, no problem getting to B. Now how do we get to Z

What is finite and easy to capture, the common events that feed these immense machines, shapes a perfect and efficient model of thought, 100 times more efficient at transactional tasks, where the details are so well defined that we could find a needle in a haystack.

But the world contains much more entropy than even we are willing to accept. It’s much messier and more chaotic. Strange events, atypical combinations or creative scenarios could leave a long tail that goes on to infinity. Or rather, they would have found the end, because they always do, but phenomenally wrong:

“Eat at least one small rock per day”… (BBC news story)

Also, in an imperfect environment like our reality, there’s another dimension that has to do with combinatorics: adding variables quickly leads to exponential combinations. For the way these models work to capture that dimensionality, we would need an enormous amount of data.

That’s why we should be careful with the illusion of having in front of us an image of ourselves, and its estimates. We still don’t have a model capable of “instant learning”. We won’t find any model that knows the art of improvising to get out of a jam.

RANT

What I wanted to say is that our work, and that of many others, will still be there: dealing with human ambiguity, battling legacy systems, struggling from one version to the next because someone decided to build on an unstable base. Designing discrete systems with an immense reality in mind.

There’s no machine that solves for us the problem of uncertainty, of long-term complexity. What does a code agent care whether the application is still working in a couple of years? The only thing that changes is that now we’re going to be buried under a mountain of code. And who is going to save us from that 80% of garbage code?

I hope you and I aren’t too lazy by the time there’s nobody left to hold accountable; when the concept of “AI first” has us digging through a cesspool that looks like it was written by an alien with attention deficit. And investors are going to love it, because it “was built in two days”. But who knows what the hell it summoned, and why it decided to import three libraries, cross dependencies and import half the internet.

The task and the goal was to be more productive, to be able to reach targets in impossible timeframes. To use modern technologies at a competitive pace without losing quality along the way, and without ceasing to build solid, scalable solutions. Do more with less. High cohesion and low coupling.

On top of that, for my part, there was the challenge of keeping the attitude of the craftsman, the blacksmith, even when industrial machinery is at hand. A task that turns into a paradox: how to see beyond what merely “works” thanks to sheer mass production and keep the passion for the craft. How to transfer this intrinsic concern for the work to a stochastic model.

First month

To resolve this paradox, in the first few weeks I had to learn in detail what I was dealing with. And maybe this is the best moment to get into the subject and tell you about Claude Code. A programming agent used through the terminal, which has access to different actions inside your computer.

At its core, “Claudito” works with the concept of context. Imagine a room with defined walls and square meters, where light comes in, along with the furniture, table and chairs, people and pets: like a finite space of information that gives meaning and limits to our reality. And this is important: you have to keep in mind the limitations and how many things fit in the room. The context must contain everything needed for the solutions Claude delivers to be valid and accurate. MCPs, for example (the tools or extended functions, for instance to simulate a browser or access Google Drive), take up a significant amount of space in your context, and can leave you without enough room to give the agent the key background of the problem, inevitably making it lose track of the solution.

I started using it with these concepts in mind, the way its own creators suggest. A sequence of explore - plan - code - commit, but as the weeks went by I felt I was repeating my own flows. So I looked for the other ways people were using this tool. And I discovered the concept of the harness and how to customize it.

Second month

The harness comes by default, and although it isn’t the most optimal for every problem or technology, it works. The agentic harness is defined as the set of tools, context management and execution environment that turns a language model into an agent.

In other words, it could be translated as the harness that holds a climber on the mountain. In climbing (unless it’s free solo), you need gear. Otherwise, you have nothing to hold on to; you have no protection. The harness is the safety equipment that connects you to the mountain. It gives you the ability to act, to be there and to move forward. And what better than having your own tools and adjusting them day by day.

Without this, the solution takes a bit longer, or you find yourself telling it the same things over and over. So, from the second month on, I added dedicated skills and commands for the patterns and technologies I use, taking inspiration from a repository (ECC, winner of Anthropic’s hackathon). All of this always implemented from a TDD (Test-Driven Development) perspective from day one. Tests here are vital, both to validate your code and to serve as a path for the models to understand it as the solution keeps growing. They are path and validation. Having the right patterns in every new plan secures my solution, but it isn’t free: there is a context and token cost attached to every plan. Although, in my opinion, it’s completely worth it.

And to make this harness work without running out of space, I leaned on persistent context, or memory. Since the session space is limited, per project you can have a CLAUDE.md file and various other .md files. These work as a usage guide; base instructions that Claude reads when starting inside a folder so it knows, beforehand, what the rules of your project are. The interplay between context and these files when working with Claudito also makes the difference.

In my opinion

With these techniques, Claude has become a snowball of productivity. It’s what it promises: things that once took me weeks now take me a couple of minutes. Analyses that might take me months, Claude solves in one well-run session with the right questions. It’s hard to look competitive in this industry without Claude as a copilot. Now, Claude doesn’t get distracted and doesn’t doubt. And it’s at your command like an army of one. Army of one.

I know I can still apply techniques to reduce token spend, and even use that crazy learning skill where Claude recognizes my workflows. I dream of the day when you just talk to the computer and interact with a machine of peculiar personality; as of today, this is the closest thing to what I once imagined. And I also know how different Claude is working on existing code and its tendency to create rather than maintain. That its way of maintaining is adding and adding code. That it has strong preferences and that if you get careless you end up creating a swarm. Its swarm, one you don’t understand. So my advice is to be careful and always keep understanding the moves toward the summit.

On the other hand, and with all that said, it’s hard to keep seeing myself as the craftsman forging the rings of power, devoted to one single, specific and spectacular task. The day-to-day shifted more toward that of a strategist, drawing routes and plans, swapping weapon types and pulling the king’s tokens as if it were war. Using the terminal and writing natural language to get what I want instead of flowing through logic gates.