State of Coding June 2026

TL;DR

If you don't use AI, you will be replaced.
If you use AI but burn your monthly token budget in one week, you will be replaced.
If you use AI without solid programming foundations, you will be replaced.

Introduction

Don't get me wrong: I love AI. I love programming with AI, and I don't see myself going back to traditional software programming. But there are a couple of things we don't talk about — or talk about too little: how to use AI properly, and the mental fatigue.

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

— Andrej Karpathy, who coined the term in early 2025

Let me start with the part nobody admits.

The pace never stops

In the last year, we've seen so much progress in our domain — so many cool things: skills, MCP (pretty old now, haha), AFK agents, and more. Yes, it's fun, especially for engineers who love software engineering and have that flame for crafting and learning things. Maybe I'm old for thinking this, but it's a lot of information to process, understand, and adopt. It isn't easy. Sometimes the thing you learned a few weeks ago is already outdated. The pace is crazy. The train is on the march.

And staying up to date becomes as important as doing your regular work. It's not easy. Sometimes I'm just tired of reading articles and seeing repetitive posts. I'm starting to hate the promising posts about the top skills to use and the perfect way to shape your prompts. Nobody teaches us the pure basics.

The lottery

The biggest downside of using AI every day is something hard to describe. But we can compare it to the lottery: we keep playing until we hit the big prize. And because it's never enough, we keep inserting coins into the machine.

The line is from @ChShersh; image shared by @Hesamation on X.

Context switching

You picked a user story from the backlog.
You prompt the agent with a solid instruction.
You review the plan. All good.
You ask the agent to implement.
It takes a few minutes.
You go on YouTube, open TikTok on your phone.
You get high on dopamine.
You come back to the agent session.
You start to read and review the code.
You can't focus.
You're annoyed at reading code.
You commit the changes.

Studies suggest that when you work on task A, stop it, and switch to task B, it can take between 27 minutes and 2 hours to regain the same level of focus on task A. This applies to any situation: a chat message, a coworker who interrupts you, a notification, a dopamine craving.

Amnesia

I have more memories of the code I wrote myself than of the code generated by the model. There are different types of memorization. Some days I come back to generated code and think… why do we have this code, what does it mean?

Proud then dumb

I feel proud when I look at the outcome. Things that would take months are done within a few days. I feel like I'm learning things. But when I go back to coding myself, I feel dumb. Like, really dumb. A simple framework snippet makes me doubt myself.

So how do you stay in the game?

@awscloud on X

All of this — the fatigue, the amnesia, the feeling dumb when you sit back down to write code yourself — has the same root: letting the machine do the thinking for you. The answer isn't using AI harder or feeding it more coins. It's the opposite. It's discipline, and it's foundations. That's what keeps you in the driver's seat.

After more than a year and a half of vibe coding, I can say it has saved my life many times — but it has also disappointed me. Sometimes the disappointment comes from simple things, which is surprising because they seem obvious to a software engineer. Here's what I lean on to stay sharp.

Rely on foundations

Pioneers in software engineering like Martin Fowler, Kent Beck, and Uncle Bob Martin are coding with AI too. But they don't put aside their architectural knowledge or expect the model to substitute for it. In fact, LLMs can't master the art of software architecture today without a bare minimum of context.

"The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x."

— Kent Beck

The 10% he means is judgment: vision, design, controlling complexity — not where the brackets go. That's the part AI can't do for you yet, and the reason foundations matter more now, not less.

Domain Driven Design

Sometimes a business requirement implies major changes across two features. If you haven't properly organized your source code, how can the LLM take the right approach — or even understand the link between these two features?
Before AI coding, the core architecture of your software (ideally) is composed of entities, also called bounded contexts: the famous DDD (Domain Driven Design). What lets two entities "talk" to each other? Interfaces. Matt Pocock explains it well in his post on how AI can understand your project faster — and work on it more efficiently.

Code review

Always review the plan. Don't rely 100% on the plan recommended by the model — though it's quite often a good option. Embedded and add-on skills exist for code review as well.

TDD

Make your codebase solid and resistant to regressions. The classic red-green loop:

• ask the agent to write the unit tests first
• run them — they all fail (red)
• ask the agent to write just enough code to pass the first failing test
• run it again until that test passes (green)
• repeat until every test is green

Your mission is to make sure the generated tests actually make sense — to you, not just to the agent.

Testing

Unit tests and integration tests are important. But it's just as important that you do your own testing. At the end of the day, your tests are also generated by the model.

Mind your context

If the lottery is about feeding coins into the machine, this is about understanding what those coins actually buy.

Token

We can't talk about context without understanding what a token is. I won't write a poem or a novel about it; here's just my definition: "The sky is blue." → 4 tokens → 4 words. Notice that I didn't count the ".". The definition of a token depends on how the model was trained.
Tokens are the coins you insert into the machine to make the magic happen. Some machines cost more tokens because they do better tricks.

Window

There might be a better word for it, but to keep it simple: this is the "prompt" we send to the machine. The machine keeps adding more and more tokens to the context. The model has a limit on how many tokens fit in its context. Beware: agentic tools like Claude Code, Kiro, Cursor, and Gravity behave differently when the context is about to overflow. That's why, after a couple of prompts, the agent starts to hallucinate. The reason is usually that the first tokens in the session get wiped out to let the latest tokens in.

Agent.md

In Kiro, we call these steering files. The idea is to provide information to the model regardless of which task it has to execute. This information describes your project in the best way: the technologies it uses and the patterns the model must follow. These documents shouldn't exceed 200–300 lines.

PRD.md

Product Requirements Document. This document lets your agent know what your project is about. It can describe requirements, business logic, and so on. You can have one or many, in different subfolders. Especially when the project is organised and separated by bounded context (domain), it's very useful to have PRD.md files.

Naming the rest

There are no golden rules or patterns here. Name each file after the content that makes sense. On legacy projects, I generate files like legacy-sso.md (legacy-featureXXX.md). Stay consistent with your conventions, and explain them at the root level (CLAUDE.md, AGENT.md, Kiro steerings, Cursor rules, and so on). Don't overload your context: have the agent auto-load these files via frontmatter, and keep each one under 200–300 lines.

Skills

You have a specific task to do, and you want the agent to perform like a pro — or to behave in a specific way. Add skills on purpose, or let the model pick skills automatically for you. Either way, skills are added to the context.

Skills aren't tied to any specific language or stack. The ones I use most are from Matt Pocock — like grill-me, tdd, and improve-codebase-architecture. I explain below why I lean so much on grill-me.

Why you're running out of tokens

There are a few leads:

• You aren't clearing your context for a new task, so you're sending unnecessary tokens to the model.
• You're using an expensive model for a simple task.
• You're trying to convince the agent to "correct" its last outcome, and you keep repeating until the context window is full.
• You're sending the whole source code into the context.

Planning & Tasking

Agentic coding comes with different built-in tools: specs in Kiro, plan in Cursor and Claude Code.
You want a top reasoning model to tackle complex features. Let it produce a solid plan with well-defined tasks. Then you can use models that are good at execution to carry out accurate, precise tasks — and they usually cost you fewer tokens.
Planning prevents the model from generating code that doesn't match your requirements and then burning unnecessary tokens.

I don't recommend specs from Kiro unless you have a lot of tokens to burn. But they're still useful if you can't provide enough detail to the agent. Here's the kind of prompt I use:

I want you to create bla-bla-bla. 
Come up with at least 3 planned options (pros and cons). 
No implementation. I will decide which plan to execute.

In Claude Code, switching to another model makes it read the whole context again. So don't hesitate to ask the performing model to write the tasks into a markdown file (especially if you use Kiro without the Spec feature). Then ask the executing model to read that file and implement the solution. An advanced technique is to delegate to sub-agents.

grill-me

This is what I'd been doing since the start of the year — then I discovered grill-me. I invite everyone to watch Matt Pocock's videos: the way he explains and exposes his knowledge of AI is quite unique. I've followed him since his TypeScript days. Excellent content, and I'm glad to see he keeps teaching AI with the same pedagogical, detailed touch.

To summarize quickly what I've understood, here's a simple example — not 100% accurate, but it should help. When you ask the AI for an immediate answer, you get the most statistically likely one:

How is the sky today?

The sky is blue.

…because "blue" is, say, 70% of the answers in its training data.

So when you ask the agent to implement a login page, it will probably take the path most represented in its training data. The agent makes that decision with no second thoughts and no challenge — just execution. Instead, you want to make the agent traverse a decision tree, and at every node challenge you. Based on your answers it refines and adjusts the task it originally set out to do. grill-me and grill-with-docs are the most essential skills you'll have in your journey: the best thing you can do is explore every possible path until the plan is cooked.

Left: straight to a guess. Right: grilled into the right plan.

Use the right model

It's a competition over who does better on task A than the other. Why not just bet on the top model from the benchmarks for the company's major release? At what cost? Which model should you pick for which kind of task?

We need to use the right model for the right task, because they don't all perform the same way — and they come with different costs.

Task	Model	Why
Planning, architecture, hard reasoning	Opus 4.X	best reasoning; worth the tokens where mistakes are expensive
Implementing well-defined tasks, most coding	Sonnet	fast and much cheaper for execution
Trivial, repetitive, high-volume edits	Haiku	cheapest; fine when there's little to reason about

Staying human

Go back to the TL;DR. If you don't use AI, you'll be left behind. If you burn your whole token budget in a week chasing the lottery, you'll be left behind. And if you lean on AI without the foundations underneath, you'll be left behind too.

So here's what that discipline looks like in practice:

• Write the docs first. Generate your Agent.md, PRD.md, and any other context files before you start. The better the agent understands your project, the less it has to guess.
• Install skills, and use them — especially for planning. Matt Pocock's grill-me (and grill-with-docs) force the agent to challenge you and walk the decision tree before a single line of code is written.
• Match the model to the job. Use a strong reasoning model like Opus 4.X to build the plan, then a faster, cheaper one like Sonnet to execute it. Accuracy where it matters, fewer tokens where it doesn't.
• Clear your context between tasks. A new task deserves a fresh window; don't make the model pay for yesterday's tokens.
• Always review the plan before you implement. It's usually a good plan — but "usually" is exactly why you read it.
• Do your own testing. The agent wrote the tests too, so you're the last line of defense.

The tools will keep changing — half the names in this post will feel dated in six months. The foundations won't, and neither will the discipline: clear your context, plan before you prompt, review what you ship, and remember that at the end of the day, the code is yours.

---

A special mention for Matt Pocock: a lot of how I work today traces back to his teaching — from his TypeScript days to his agent skills. His skills repo, pulled straight from his own .claude directory, has crossed 127k stars — and every one of them is deserved. Go star it, then go grill your agents.