Learning something in 2026

I’ve been a bit away from the software industry for about ~1.5 years now. The biggest thing that I missed during this time entirely was the advent of capable AI Agents.

Before this, I’ve played around with Claude Code, Codex, Aider etc. But I shipped nothing concrete or of value.

A worthy personal project

I look at software as a tool to solve problems. With work, it solves problems in your business. With personal projects, it should be solving a particular problem that you (or others) face.

Personal projects should be FUN to build so you're motivated enough to learn the nuances of new tech you find along the way.

I've been cooking a bit for myself in the past year and I've gotten attached to some Youtubers and Chefs whose recipes fit my taste (Venkatesh Bhat shoutout). Most days, I choose a video-recipe, buying it's ingredients and then cooking it. Some days, I feel lazy and I don't want to drop by to the market to get the ingredients. So I found myself manually going through videos based on the ingredients I had.

This was annoying and I wanted a cooking search engine which suggests me recipes based on the ingredients I have. And as any true-blue software engineer would, I had to build a solution tailored for me instead of using any existing solutions.

The board was set, I thought about it for a day and came up with a plan - transcribe the video-recipes, fetch the required ingredients and put them in a DB for lookup later. It's a lot more complex than this is more of a 10k feet view.

A mix of Langgraph, transcription tools and even Livekit for a voice agent (feature creep before I even start ;). A couple of new frameworks that I haven't worked with before extensively.

Building the project

I jumped straight into their Getting Started pages and gave it a brief read. I played around with it to get the basic hang of things. I move onto actually building the app, but this time I use Claude Code extensively to speed things up.

Aside brainstorming and generating a plan with the specifics, Claude was writing most of my code with me reviewing it at the end. Since I was working with new frameworks, there were a lot of APIs, functions, etc that I wasn't aware of.

I'll split unknown code into 2 parts - code that felt unfamiliar (say Type A) and code that reads like familiar psuedo-code (Type B).

Type A

With Type A, I checked the docs and how it is used by other people (blogs, Github searches etc).

For ex, model.astream where I wanted to know more about the streaming API and how it handles text chunks, etc. Another example is the usage of Command to route Langgraph instead of Conditional Edges.

Type B

With Type B, it was more of "does this code structurally check out". This is for straightforward code that does a simple job.

For ex - model.invoke or model.with_structured_output.invoke. Just by reading the code, you know what invoke or with_structured_output does.

If it checks out structurally, you read it as psuedocode and move on.

The Type A : Type B Ratio

The ratio between what you consider as Type A or Type B is pretty important and delicate. Too much Type A will cost you speed whereas too much Type B borders on the line of vibecoding.

This is a very tricky ratio to balance, particularly for learning. If my personal project takes ages to complete, other priorities take over and/or I tend to lose motivation sometimes. If I rush through the project, I lose out on learning the nuance and depth.

Necessity for Friction

Friction is the conflict between your understanding and the truth (i.e. what happens in reality).

When faced with this conflict, you try something new, test it, fail. Rinse and repeat till you succeed. By reflecting on what worked and what didn't, you have a much better understanding in the end.

This often includes asking a set of questions across multiple perspectives. Some examples from my project -

1. Why should I use one API over the other ? Command vs Conditional Edges and where to use them.

2. Why does a library sometimes box users into designing components a particular way ? For ex, why does Langgraph not allow streaming in with_structured_output ?

It is important to note that not all friction is good. Sometimes it is good to eliminate bad friction (ex: boilerplate code) and automate that work entirely.

So you also need to be tactical about the kind of friction you focus on.

Before Agentic AI coding, we were forced to understand code before writing it. But the game has changed now, and this not limited to just code but anything that is AI-generated.

The Newer Generation of Engineers

I'm digressing a bit, but I want to talk about the newer generation of engineers coming into the industry, who've never had to hand-write code by themselves.

With the advent of AI-assisted coding, managers/PMs/etc are going to expect work to be done faster.

Newer engineers are not familiar with the concept of pushing back, nor do they have a lot of trust from their managers. So the total time available to learn and better your understanding is entirely on your manager and the company's culture.

Even if you have the time, you also need motivation to learn something difficult. It's a mix of personal drive, company culture and work-constraints. Companies, mentors and managers should encourage and provide space for newer engineers to learn while also getting the work done. This differentiates a good engineering culture vs a bad one.

It should be a more widely spoken conversation (if not already) as it defines the next generation of Senior+ Engineers.

Future of Learning

Moving forward, we need to allocate time and space to substitute the learning from this "lost friction" in AI-assisted work.

There's a lot of ways to do this but I think practising curiosity is fundamentally it.

I'm still reading and ironing out my processes on substituting for this lost friction. I'll either add to this or a separate article later.

To start off with, I realized that it is important to reflect on what you learnt when you worked on something new. My blog and this post is a nice starting place for my reflection.

If you've made it till here, thank you for your time and feel free to comment your thoughts :)