The paradigm shift in programming

We’re living through one of the most significant transformations in how software gets written. The rise of Agentic AI has changed everything about the engineer’s experience. Gone are the days when AI assistance meant autocomplete suggestions or simple code snippets. Today’s AI agents can reason about codebases, execute multi-step tasks, browse documentation, and iterate on solutions autonomously.

This isn’t hyperbole. The shift from traditional coding to AI-assisted development mirrors previous paradigm shifts like the transition from assembly to high-level languages, or from monolithic architectures to microservices. But this one hits different - it changes how we think about problems, not just how we express solutions.

Before Agentic AI, an engineer’s workflow was research → plan → implement → debug → repeat. Now it’s describe intent → review generated code → refine context → iterate with the agent → validate. The cognitive load shifts from “how do I write this” to “how do I communicate what I want effectively.”

This transformation demands new skills. Understanding context windows, crafting effective prompts, knowing when to intervene versus when to let the agent work. Engineers who master these skills multiply their output. Those who don’t risk becoming bottlenecks in their own workflows.

The question isn’t whether AI will change programming. It already has. The question is whether you’ll adapt your practices to leverage it effectively or keep resisting until it’s too late.

How LLMs and AI agents actually work

Understanding how these tools work under the hood isn’t just academic, it’s essential for using them effectively. Since this isn’t a deep dive into LLMs and AI agents, we won’t be going too much in depth but rather just covering some topics at high level.

Context and prompts drive everything

Large Language Models are sophisticated pattern matchers. That’s it. They predict the most likely next token based on everything you’ve given them. Garbage in, garbage out.

If you don’t provide proper context, don’t expect the AI to magically solve your problems. An LLM has no inherent knowledge of your codebase, your conventions, your business requirements, or your constraints. Everything it needs to produce useful output must come from you.

The importance of context windows

The context window is the total amount of text (measured in tokens) that an LLM can consider at once. Think of it as the AI’s working memory. Modern models have made massive leaps here. As of early 2026, we have models with context windows exceeding 1 million tokens. Llama 4 Scout leads with a staggering 10M tokens, Grok 4 offers 2M, and Gemini 3 Pro, Claude 4.5 Sonnet, and GPT-4.1 all support 1M tokens.

Bigger isn’t always better though. And this isn’t just my opinion. It’s backed by research and Google’s own benchmarks.

The “Lost in the Middle” paper demonstrated that LLMs struggle to retrieve information placed in the middle of long contexts. They perform best when relevant information is at the beginning or end, but accuracy drops significantly for content buried in the middle.

Google’s own MRCR v2 benchmarks tell the story clearly. Gemini 3 Pro scores 67.2% accuracy at 128K tokens but plummets to just 22.1% at 1M tokens. Gemini 3 Flash drops from 77.0% to 26.3%. GPT-4.1 falls from 54.3% to 21.0%. That’s roughly a 67% performance drop when using the full context window.

The irony is almost poetic. We wanted larger context windows because models were forgetting older things, but larger windows just give us more space to lose information in. Stuffing irrelevant information into context makes it harder for the model to focus on what matters. This is why tools with good context management outperform naive “dump everything” approaches.

How Agentic AI differs from chat

Traditional chat-based AI is reactive, you prompt, it responds, conversation ends. Agentic AI is proactive. It can

• Break complex tasks into subtasks
• Execute code and observe results
• Search the web or documentation
• Iterate on its own output based on feedback
• Use tools to accomplish goals

Your job becomes supervision and course correction rather than micromanagement. You describe goals, let the agent figure out the steps. No more crafting the perfect prompt.

AI hallucinates. Demand receipts.

LLMs will confidently lie to your face. They’ll invent API methods that don’t exist, cite documentation that was never written, recommend libraries deprecated years ago. This isn’t malice - it’s how these models work. They predict plausible-sounding text, and sometimes plausible-sounding is just fiction.

The solution? Demand receipts. Don’t be a victim of “Source: Trust me bro.” Always ask the AI to provide citations, links to documentation, or specific version numbers. If it claims a function exists, ask it to show you where in the docs. If it recommends a library, ask for the GitHub repo or npm package. Treat every factual claim as “trust but verify.”

Better yet, use tools that fetch live documentation. MCP servers like Context7 can pull the latest docs directly into your AI’s context, so you’re not relying on training data from months or years ago. This is especially critical for fast-moving ecosystems where APIs change frequently. When the AI has access to current documentation instead of stale training data, the hallucination rate plummets.

The pattern I follow is simple. If the AI suggests something I haven’t seen before, I verify it independently before using it. A quick search, a docs lookup, a test in scratch file. Thirty seconds of verification saves hours of debugging phantom APIs that never existed.

AI lacks your domain knowledge

AI doesn’t know your codebase. Not really. It lacks the domain knowledge and nuances you’ve built over years. It doesn’t know why that weird workaround exists in the payment module, or that the legacy API has undocumented rate limits, or that certain customers depend on behavior that looks like a bug. These things live in your head, in tribal knowledge, in confluence documents, in commit messages from three years ago. An AI can pattern-match code, but it can’t pattern-match institutional context. At least not yet. Your experience and domain expertise remain irreplaceable - lean into that.

With great power comes great responsibility

Now that you understand how these tools work, let’s talk about how to use them responsibly.

The difference between vibe coding and vibe engineering

Simon Willison nailed this distinction in his piece on Vibe Engineering.

Vibe coding is YOLO prompting. Throw requests at an AI, accept whatever comes back, hope it works. Seductive because it feels fast. But it produces AI slop - code that technically runs but is brittle, unmaintainable, and poorly understood by the person who “wrote” it. Obnoxious amounts of code you can’t explain.

Vibe engineering, on the other hand, is what serious engineers do. You use AI as a powerful collaborator while maintaining engineering discipline. You understand what the AI produces, you review it critically, you iterate with purpose, and you ensure the output meets your quality standards.

The difference comes down to intentionality. Vibe engineering means you’re still the engineer, AI is your tool. Vibe coding means you’ve abdicated engineering responsibility to a probabilistic text generator.

Preventing AI slop

My approach to avoiding the AI slop trap:

Never accept code you don’t understand. If the AI produces something and you can’t explain why it works, you don’t ship it. Period. Take the time to understand, ask the AI to explain, or rewrite it yourself. Treat AI-generated code with the same scrutiny you’d apply to a junior developer’s pull request - check for edge cases, security issues, and alignment with your codebase conventions.

Keep your fundamentals sharp. AI amplifies your abilities but doesn’t replace them. If you stop understanding fundamentals, architectures, data structures & algorithms, system design and nuances of your languages & framework, you lose the ability to evaluate AI output effectively. Commit incrementally too. Small, reviewable changes beat massive AI-generated rewrites. If you can’t review it, you can’t trust it.

Don’t outsource your critical thinking

If you let AI do all your thinking, you’ll eventually become unable to think for yourself. Your brain is a muscle. Atrophies without exercise.

As engineers, we must stay in the driver’s seat. AI should amplify our thinking, not replace it. When you stop reasoning through problems, stop understanding tradeoffs, stop building mental models of systems… you’re not becoming more efficient. You’re becoming less capable.

I’ve seen engineers who can’t debug without AI anymore. They’ve outsourced so much cognitive work that when the AI gives wrong answers (and it will), they lack the foundational understanding to recognize the errors. They’ve traded their expertise for convenience.

Use AI as a collaborator, not a crutch. When the AI suggests something, ask yourself - Do I understand why this works? Could I have arrived at this solution myself? If the answer is no, that’s your cue to dig deeper, not to click accept.

The goal isn’t to minimize thinking. The goal is to redirect your thinking toward higher-leverage problems while maintaining the foundational skills that make you a capable engineer. Exercise your grey matter, or lose it.

My recommendations for productive AI-assisted development

Choose your models wisely

Not all LLMs are created equal. Your choice of model can make or break output quality. State-of-the-art (SOTA) models consistently outperform their predecessors on reasoning, code generation, and following complex instructions. Using an older or weaker model because it’s cheaper often costs you more in debugging time and rework.

Modern tools like GitHub Copilot, Cursor and Windsurf now let you choose which model powers your assistant. This is a big deal. When you’re doing complex refactoring or architectural work, switching to a more capable model (even temporarily) can save hours of back-and-forth.

My approach: faster, cheaper models for simple tasks like generating boilerplate, data classes, or writing tests. Switch to SOTA models when I need deeper reasoning, complex debugging, architecture decisions, or working with unfamiliar codebases. The extra cost is almost always worth it for the hard stuff.

Start with research and plan mode

This is where AI agents truly shine, and it’s where every task should begin. Before writing any code, use agents for discovery and planning.

When I’m exploring a new technology or architecture decision, I don’t start by reading documentation. I start by asking an agent to summarize the landscape, compare approaches, and identify potential pitfalls. The agent scouts multiple sources, synthesizes findings, compares libraries objectively, surfaces gotchas from real-world usage. Generates pros/cons lists. This doesn’t replace deep reading when needed, but it accelerates discovery like nothing else.

Once I have context, I use plan mode religiously. Tools like Claude Code, OpenCode, and Cursor all offer this feature. Plan mode asks the AI to outline its approach before executing - you catch misunderstandings before they become wasted effort, the AI’s plan often reveals approaches you hadn’t considered, and you can steer the direction before committing to implementation.

I’ve had countless instances where the AI’s plan included open questions I hadn’t imagined. The combination of research + plan mode means I arrive at implementation with clarity about what I’m building and why.

Let agents handle ceremonial work, you handle business logic

Nobody talks about this part. Engineers have an itch to solve problems. It’s why we got into this field. That dopamine hit when you finally crack a tricky bug, when an elegant solution clicks into place, when tests go green after hours of debugging - that’s the good stuff. That’s what makes this job worth doing.

Vibe coding takes that away. When AI writes everything and you just accept, you’re babysitting a text generator. Clicking accept on obnoxious amounts of code you didn’t write. The satisfaction evaporates.

I present to you my favorite pattern. I ask the agent to scaffold the boring parts and mark TODOs for the parts that require human judgment & business logic.

“Set up the repository structure, update Gradle with necessary dependencies, create DI providers, create the contract and its implementation class, and mark TODOs where I need to implement the actual business logic.”

This offloads tasks I’ve done a thousand times and gives me a working skeleton I can run immediately, with clear markers for where my expertise is needed. I get the satisfaction of solving the interesting problems myself while avoiding the tedium of boilerplate. The AI handles the ceremony, I handle the substance. I still get that dopamine hit when I nail the business logic, because I actually solved it. And I have confidence that the plumbing is correct because it follows standard patterns.

Generate small, reviewable changes

This is critical. When you ask an AI to make large changes, you create a binary choice. Accept blindly or start from scratch. Neither is good.

Instead, request incremental changes.

• “Add the database model first, we’ll add the API next”
• “Refactor this function, don’t touch the calling code yet”
• “Implement the happy path, we’ll handle errors in the next iteration”

Small changes are reviewable. You can verify each step, catch issues early, iterate in the right direction, steer the LLM immediately when it makes a mistake, and maintain understanding of your codebase. Large changes tempt you to click “accept all” and hope for the best.

Use AI agents to review code changes

Code review is cognitively expensive. AI agents can handle the first pass - checking for obvious bugs, security issues, anti-patterns, verifying consistency with existing codebase conventions, identifying missing tests or documentation, and suggesting improvements to readability or performance.

This doesn’t replace human review for complex changes, but it catches low-hanging fruit and lets human reviewers focus on architecture, business logic, and subtle issues that require domain knowledge.

Use AI for interactive learning

One of the most underutilized features of modern AI platforms is their learn mode. ChatGPT, Claude, and Gemini all offer interactive learning experiences. This changes how we acquire new knowledge.

Unlike traditional documentation that throws walls of text at you, learn mode gives you digestible chunks - a couple of paragraphs at a time. It pauses to let you ask questions, clarify concepts, and decide where to dive deeper. You control the direction of your learning journey. This is particularly powerful for learning new languages or frameworks, understanding complex architectural patterns, diving into unfamiliar codebases, or grasping mathematical and algorithmic concepts.

I also want to highlight Code Wiki, a relatively new tool from Google that’s incredibly powerful for learning codebases. Code Wiki uses Gemini to automatically generate and maintain interactive documentation from your code. It creates section-by-section breakdowns so you can focus on specific parts and dive deeper, generates auto-updating docs that stay in sync with every merged PR so you are not reading about how code was months back, lets you chat with your codebase to ask questions about architecture or find function definitions, and transforms complex systems into clear architectural visualizations with direct links from documentation to code.

Stop reading passive documentation. Start having conversations with AI that adapt to your pace and prior knowledge.

Set up solid AGENTS.md / CLAUDE.md files

Most AI coding tools look for configuration files that provide persistent context. This is your opportunity to encode your preferences, constraints, and conventions once and have them apply to every interaction.

A good AGENTS.md file includes a project structure overview (where things live, naming conventions), your technology stack (languages, frameworks, versions), code style preferences (formatting, patterns you prefer or avoid), testing conventions (how and where tests should be written), and common commands (build, test, lint, deploy).

But don’t overdo it. Every instruction consumes context window tokens. I’ve seen AGENTS.md files with obnoxious amounts of edge cases - 5000 words of instructions that bloat every interaction with noise. Keep it concise. Iterate as you discover what actually helps.

My rule is simple. If I find myself repeatedly correcting the AI on something, it goes in AGENTS.md. If I’ve never needed to correct it, it probably doesn’t need to be there.

Summary

The age of Agentic AI has arrived, and it’s reshaping how we write software. This isn’t a future prediction, it’s the present reality. Engineers who adapt their practices will multiply their productivity. Those who don’t will struggle to keep pace.

• Understand how LLMs work so you can leverage them effectively. They’re pattern matchers that need good context to produce good output.
• Remember that AI hallucinates and lacks your domain knowledge. Verify claims and lean into your expertise.
• Embrace the paradigm shift but maintain engineering discipline.
• Avoid AI slop through critical review and incremental changes.
• Stay in the driver’s seat and don’t outsource your critical thinking.
• Choose your models wisely. SOTA for complex work, faster models for routine tasks.
• Start every task with research and plan mode to arrive at implementation with clarity.
• Let AI handle ceremony while you focus on business logic.
• Generate small changes that are easy to review and verify.
• Use AI for interactive learning to master new technologies faster.
• Configure your tools with concise, relevant instructions.

AI doesn’t replace good engineering judgment. It amplifies it. The engineers who thrive? They collaborate with AI effectively while never forgetting one thing: they’re still responsible for what ships.

Closing note

The best engineers I know aren’t threatened by AI. They’re excited by it. They see it as the most powerful tool they’ve ever had access to, and they’re actively learning how to wield it effectively.

But they also haven’t abandoned their craft. They still understand systems deeply. They still review code critically. They still take responsibility for what they ship.

That balance - leveraging AI’s power while maintaining engineering discipline - is what separates engineers who thrive in this era from those who drown in AI slop.

The tools will keep improving. The models will keep getting better. But the fundamental skill of knowing how to work with AI rather than for AI? That’s on you to develop.

Start now. Experiment deliberately. Learn what works. And never stop being the ENGINEER.

Glossary

Agentic AI

AI systems that can autonomously perform multi-step tasks, use tools, and iterate on their outputs to achieve goals. Unlike simple chat interfaces, agentic AI can execute code, browse the web, and make decisions about how to accomplish objectives.

AI slop

Low-quality, poorly understood code produced by accepting AI outputs without critical review. Characterized by working-but-brittle implementations that the engineer cannot explain or maintain.

Code Wiki

A Google tool that uses Gemini AI to automatically generate and maintain interactive documentation from codebases. Features include chat-based codebase exploration, auto-updating docs, architectural diagrams, and direct links from documentation to code definitions. See codewiki.google.

AGENTS.md

A configuration file (also CLAUDE.md, .cursorrules, etc.) that provides persistent context to AI coding tools. Contains project-specific instructions, conventions, and preferences that apply to all interactions.

Context window

The maximum amount of text (measured in tokens) that a language model can process in a single interaction. Acts as the model’s working memory, determining how much information it can consider when generating responses.

Hallucination

When an LLM generates plausible-sounding but factually incorrect information. This includes inventing API methods, citing nonexistent documentation, or recommending deprecated libraries. Combat this by demanding citations and using tools like MCP servers to fetch live documentation.

Large Language Model (LLM)

A neural network trained on vast text corpora that predicts the next token in a sequence. The underlying technology powering modern AI assistants like Claude, GPT, and Gemini.

MCP (Model Context Protocol)

A protocol that allows AI assistants to connect to external tools and data sources. MCP servers like Context7 can fetch live documentation, query databases, or interact with APIs, giving the AI access to current information beyond its training data cutoff. See modelcontextprotocol.io.

Prompt

The input text provided to an LLM that guides its response. Effective prompting includes clear instructions, relevant context, and explicit constraints.

Token

The basic unit of text processing for LLMs. Roughly corresponds to 4 characters or 0.75 words in English. Both input context and output are measured in tokens.

Vibe coding

Unstructured AI-assisted development where prompts are thrown at models without intentionality, outputs are accepted without review, and engineering discipline is abandoned. Produces AI slop.

Vibe engineering

Disciplined AI-assisted development that maintains engineering rigor while leveraging AI capabilities. Characterized by intentional prompting, critical review, and maintained understanding of generated code.