From Typing Code to Directing Agents: How AI Changed Coding and What to Do About It
What Is Agentic Engineering, and How It Can Be Used in Coding?
Welcome to the 45th issue of AI Agents Simplified 🍻
This issue is brought to you by Reddit
There’s a version of this shift that gets talked about a lot. AI writes code now. Developers are either thriving or worried. Pick a side.
That framing misses almost everything interesting about what’s actually happening.
The real shift isn’t just about speed or job security. It’s about how the act of building software has changed, what it looks like, what it demands from you, and what it punishes you for getting wrong. And most people, technical or not, are only seeing one part of it.
This post is about all of it.
Before any of this: what coding actually looked like
Picture a developer in 2018. A blank file open on the left. Documentation on the right. Stack Overflow in a third tab. Maybe a linter running quietly in the background, underlining things in red.
Every line gets typed by hand. When something doesn’t work, you search for the error message, find a forum post from 2016, hope the answer still applies, adapt it, try again. The process is: think → search → write → test → repeat.
The bottleneck is always the human. How fast can you type. How much syntax you remember. How quickly you can find the right answer buried in a thread somewhere.
It’s slow. It’s granular. And in a strange way, it’s intimate, you know exactly what’s in your codebase because you put every piece of it there yourself.
That’s the before picture. Hold it in your head, because everything that comes next is a contrast to it.
How AI entered the picture and what changed each time
AI didn’t arrive at coding all at once. It came in stages, and each stage changed a different part of the workflow.
In the early 2020s, the first tools could finish a line you’d started. You’d type half a function signature and the model would guess the rest. Useful, occasionally impressive, but you were still doing all the thinking. The AI was autocomplete with better instincts.
Then in 2022, GitHub Copilot broke through. Now you could describe what you wanted in plain language and get a full function back. Millions of developers started using it. For the first time it felt like the tool understood the task, not just the syntax. But it was still making suggestions. You were still the one deciding, reviewing, approving.
Then something shifted in late 2024 and into 2025. The models stopped just suggesting. They started executing. (Karpathy, Sequoia AI Ascent 2026)
You give the agent a task. It reads your existing files, figures out which ones are relevant, makes the changes, runs the tests itself, and comes back with a pull request ready for your review. It’s not finishing your sentences anymore. It’s doing the work.
Brendan O’Leary puts it well: “We’re no longer just using machines. We’re now working with them.” (Agentic Engineering: Working With AI, Not Just Using It) The word choice matters. Tools are things you pick up and put down. You work with a collaborator.
That’s the current state of AI coding. And most people reading this are already somewhere inside it, even if they don’t have a name for what they’re doing.
Thinking about Reddit ads?
Get $500 in free credit when you spend $500 and expert 1:1 guidance
500M+ people use Reddit every month. By showing up where these users research and validate products, you can tap into the conversations that drive more trust and higher conversions.
And making ads is simple: with the Simple Create campaign builder, you can launch in minutes. Plus, Reddit offers free, 1:1 guidance from an ads expert to help you start and optimize your campaign.
Reach your audience on the platform they already trust.
👉 New accounts only, limit 1 per account, additional terms apply.
What an AI coding session actually looks like today
Here’s what the workflow looks like now, concretely.
You open your coding agent like Claude Code, Cursor, Kilo, whatever you use. You don’t start by writing code. You start by describing a problem. What needs to change. What context is relevant. What the goal is.
The agent reads your codebase. It figures out which files are involved. It maps out what it thinks needs to happen. Then it starts making changes, and here’s the critical part, it shows you a diff. Not a blank file where you have to build something from scratch. A set of proposed changes that you read, evaluate, and either approve or push back on.
You’re not typing syntax. You’re making decisions. Accept this. Reject that. That approach is wrong, try it this way instead. The agent adjusts and continues.
The bottleneck has moved. It used to be how fast you could write. Now it’s the quality of your judgment, knowing what to approve, what to question, what direction to steer things when they go sideways.
That’s modern AI-assisted coding. And if that description feels familiar, it should. Because there’s already a name for a version of it that most people are doing right now.
That workflow you just pictured, that’s vibe coding
Vibe coding is what happens when you do everything I just described, but without a disciplined process around it. You prompt, the agent produces, you accept, you ship.
Andrej Karpathy coined the term in February 2025. The idea was simple: you give into the vibes. You describe what you want, you let the AI build it, and you don’t worry too much about reading every line it generates. (from vibe coding to agentic engineering, Sequoia AI Ascent 2026)
And honestly? For a lot of use cases, it works. You can scaffold an app in an afternoon. You can build a prototype that would have taken a week. The floor of what’s possible has risen dramatically, anyone can build something now, regardless of how much syntax they know.
But there’s a problem. And it doesn’t show up immediately. It shows up the third time you try to change something, or the sixth, or when you need to hand the codebase to someone else.
Why vibe coding breaks and what actually breaks it
Matt Pocock made an argument recently that I think is the clearest diagnosis of this problem. (Software Fundamentals Matter More Than Ever, AI Engineer Conference 2025)
He was teaching a course on AI coding and kept noticing the same pattern: people would run a specs-to-code workflow, get output, run it again, get worse output, run it again, get something almost unusable. The code degraded with every iteration.
The reason, he argues, is software entropy. Every time you make a change to a codebase without thinking about the design of the whole system, the codebase gets a little harder to change. A little more tangled. A little more fragile.
He pulls this from two books worth knowing:
A Philosophy of Software Design by John Ousterhout defines complexity as anything that makes a system hard to understand and modify. A bad codebase isn’t one that doesn’t work, it’s one you can’t change without breaking something else.
The Pragmatic Programmer calls this software entropy: systems tend toward disorder unless someone is actively investing in their design.
The uncomfortable truth Pocock lands on is that bad code is more expensive now than it’s ever been. If your codebase is a mess, AI can’t help you, it just generates more mess, faster. But if your codebase is clean and well-structured, AI thrives in it. Good code matters more in the AI era, not less.
And vibe coding, by design, doesn’t invest in the code. It accepts the output, moves on, and lets the entropy accumulate quietly.
There’s a sharper version of this problem too. One of the most quoted lines from the AI engineering world right now is this one from Karpathy: “You can outsource your thinking, but you can’t outsource your understanding.” (Sequoia AI Ascent 2026)
When you stop reading what the agent produces, you stop building the instinct that tells you when something is wrong. And once that instinct is gone, what engineers sometimes call proprioception, the feel for the code, no amount of diff-reviewing brings it back. (Agentic Engineering Explained: Why Vibe Coding Is Over)
That’s the real cost of vibe coding done carelessly. Not the bad output. The degraded judgment.
Explore Degree Programs Tailored to You
At Education Directory, we understand that choosing the right degree program is a crucial step toward your future success. Our platform offers personalized assistance to help you discover programs that match your interests and career objectives.
How it works:
Step 1: Explore Areas of Study
Expand your skills or start something new, discover colleges by subject areas that matter to you.
Step 2: Refine Your Search
Narrow down your college search based on your desired interests
Step 3: Compare Institutions
Compare top schools and decide which institutions best fit your need
This is an offer for educational opportunities and not an offer for nor a guarantee of employment. Students should consult with a representative from the school they select to learn more about career opportunities in that field. Program outcomes vary according to each institution’s specific program curriculum.
Agentic engineering: the discipline that responds to all of this
Karpathy introduced agentic engineering at Sequoia’s AI Ascent conference in early 2026 with a line that’s been quoted a lot: “Vibe coding raises the floor. Agentic engineering raises the ceiling.” (Sequoia AI Ascent 2026)
The distinction matters. Vibe coding is about access, anyone can build something now. Agentic engineering is about quality, can you build something that holds up, scales, and can be maintained?
The shift in the workflow is concrete. Instead of prompt → accept → ship, the discipline looks more like this:
Research first. Before a single line of code gets written, you and the agent work together to understand the problem. What files are involved? What are the edge cases? What should stay exactly as it is? The output of this phase isn’t code, it’s a shared understanding. O’Leary describes this as the highest-leverage use of your time in the entire process. (Agentic Engineering: Working With AI, Not Just Using It)
Plan before implementing. Once you understand the problem, the agent produces a written plan. Step-by-step changes. What will be touched, what won’t. How you’ll verify the result. You read it. You push back where you disagree. Nothing gets built until you’ve signed off on the direction.
Implement against a spec you understand. Now the agent writes the code, but against a plan you’ve already approved. You review the diffs the way a senior engineer reviews a junior’s pull request. You know what you’re looking for because you were part of designing the approach.
The human role in this workflow is specific: you’re not typing, and you’re not just accepting. You’re defining the problem, holding the architectural judgment, and catching the things the agent will confidently get wrong.
Because it will get things wrong. O’Leary’s mental model for this is useful, think of your AI agent as an extremely well-read, energetic, often confidently wrong junior developer. Incredible breadth of knowledge. No judgment about your specific context. It’ll write code that’s technically correct and contextually backwards, and it won’t hesitate. (Agentic Engineering: Working With AI, Not Just Using It)
Your job is to be the senior engineer in the room.
The craft inside the discipline: why context is everything
Once you understand agentic engineering as a discipline, the next question is: what’s the actual skill you develop inside it?
The answer is context engineering.
Everything the agent knows about your project, your conventions, your architectural decisions, your constraints, what you’re trying to build and why, has to come from you. The model has no memory between sessions. Every time you open a new conversation, you’re briefing a new hire who has read every piece of software documentation ever written but knows nothing about your specific situation.
The quality of that briefing determines the quality of the output.
Andrej Karpathy describes context engineering as “the delicate art and science of filling the context window with just what needs to happen for the agent to have the right context for the right iteration.” (Sequoia AI Ascent 2026)
What that means in practice: more context isn’t better. Better context is better. O’Leary points out that once a context window gets past roughly 50% full, output quality can actually degrade, the model gets slower, more confused, more likely to make mistakes. (Agentic Engineering: Working With AI, Not Just Using It) Bad context doesn’t just produce mediocre output. It can poison the whole session.
Patrick Debois made this argument at the AI Engineer Conference 2026. His claim: context needs to be treated the way we learned to treat code. Versioned. Tested. Maintained. Not written once and forgotten, but actively managed as an asset. (Context is the New Code, AI Engineer Conference 2026)
Most people are still treating their prompts and instructions like sticky notes. Quick, disposable, person-specific. Debois is arguing they should be treated like shared infrastructure.
The analogy that makes this concrete: imagine briefing that junior developer I mentioned, the one who’s read everything but knows nothing about your project. If your briefing is vague, they’ll fill in the gaps with whatever they think makes sense. If it’s precise, here’s the project, here are our conventions, here’s what we’ve already decided and why, they can actually help you.
The briefing is the context. Getting good at writing it, maintaining it, improving it, that’s the craft.
What I actually think about all of this
Most people are treating this shift as a single question: should I use AI for coding or not? That’s the wrong question. The shift has already happened. The more useful question is: which part of the workflow are you actually in charge of?
If you’re accepting outputs without understanding them, you’re vibe coding and your codebase is accumulating debt you can’t see yet. If you’re directing, reviewing, and maintaining judgment over the whole process, you’re doing something closer to agentic engineering and you’re probably getting substantially more out of the tools.
The thing that strikes me most in all of these talks is that none of the people who understand this shift deeply are saying AI makes engineering skill less important. They’re all saying the opposite. Karpathy still cares about understanding. Pocock is still citing software design books from 20 years ago. O’Leary is still talking about the judgment you bring to reviewing a diff.
The fundamentals didn’t get cheaper. The cost of ignoring them just got higher.
The question I'd leave you with
Think about your current workflow, however you’re using AI tools right now, in code or in any other kind of knowledge work.
At which step are you genuinely in charge? Not just present, but actually directing, evaluating, understanding what’s happening and why?
That’s the gap worth closing. Not the gap between using AI and not using it the gap between using it and understanding what you’re handing over when you do.
The shift from typist to director moves the unit of skill in a way most developers haven't named yet. Code-craft is necessary but no longer sufficient. Two new disciplines do the load-bearing work now. Spec-craft: writing the framing, constraints, and acceptance criteria precisely enough that a competent agent produces the right thing on the first or second try, instead of negotiating across ten. Supervision-craft: reading agent output for the failure modes that don't trip your tests but will surface later. Both are real skills. Both decay if you don't practice them. The agentic engineers who get great are the ones who treat those two as their primary craft, not as overhead between the real work.
Lots to think about here. I use the tools for a couple tasks. I usually write a number of bullet points of what I want to cover in a post. Send it off to a custom skill to give me a first draft. I'll edit it then have another custom agent review it and ask me about issues or gaps it sees before it makes its own edits. I review/edit/approve. Publish skill sends it to where I publish. I do the "taste" parts, AI does the drudgery.