In June 2026, Forbes published a piece asking whether vibe coding is already dead, pointing to Andrej Karpathy's shift from "vibe coding" toward "agentic engineering." The article captures something many software teams already feel: the way we build software has changed faster than our vocabulary.

Vibe coding was the phase where you described what you wanted and an AI tool generated code. Agentic engineering goes further. You give an AI agent a goal, it writes code, runs tests, reads errors, fixes issues, and reports back. The human role moves from typing every line to directing the work.

That shift is real. But there is a dangerous interpretation of it.

The wrong conclusion is: "I no longer need to understand software. The agent will build it for me."

The better conclusion is: "I may never write code the way I did before, but I need stronger fundamentals than ever because now I am responsible for reviewing, guiding, and trusting much more output than I personally typed."

AI can help you build faster. Without technical understanding, it can also help you build a faster house of cards.

What is agentic engineering?

Agentic engineering is software development where AI agents perform multi-step engineering tasks with a degree of autonomy. Instead of asking for a single code snippet, you ask an agent to complete a task: inspect the codebase, propose a plan, implement changes, run tests, fix failures, and summarize what changed.

The difference from traditional coding is not only speed. It is the shape of the work.

Traditional development often looked like this:

Understand the requirement.
Design the solution.
Write the code.
Test the code.
Debug the code.
Deploy the code.

Agentic engineering looks more like this:

Define the goal clearly.
Give the agent context and constraints.
Review the agent's plan.
Let the agent implement.
Inspect the diff.
Run or verify tests.
Ask the agent to explain risks.
Decide whether the result is safe to ship.

That is still engineering. It is just less about manually producing every character and more about judgment, decomposition, review, architecture, and accountability.

You will not write code like before

For current developers, this can feel uncomfortable. A large part of our identity has been tied to writing code. We learned syntax, frameworks, editors, shortcuts, and debugging habits. We got good at turning vague ideas into working systems by typing and thinking at the same time.

AI changes that workflow.

You will still write code, but less of your value will come from being the fastest person at producing boilerplate. Agents are already good at scaffolding components, generating tests, wiring API calls, writing migration drafts, refactoring repetitive patterns, and explaining unfamiliar code.

The developer's value moves upward.

The important questions become:

Is this the right problem to solve?
Is the requirement precise enough?
Does the architecture fit the future of the product?
Did the agent preserve existing behavior?
Are the tests meaningful or just performative?
Is there a security, privacy, or data integrity risk?
Will another developer understand this in six months?
Is this solution simple enough?

In other words, AI reduces the cost of producing code. It does not reduce the need for engineering judgment.

The house of cards problem

AI-generated software often looks impressive at first glance. The app runs. The page renders. The API responds. The demo works.

That is not the same as having a solid system.

A house of cards can stand for a moment. It can even look elegant. But every new card increases the risk because the foundation was never designed to carry weight.

In software, this happens when people use AI agents without enough understanding to review the output. The first version feels magical. The second feature still works. By the fifth feature, nobody understands why the state is duplicated, why the database model is awkward, why authentication has edge cases, or why one small change breaks three unrelated screens.

Common symptoms include:

Code that works only for the happy path.
Tests that assert implementation details but miss real behavior.
Database schemas that cannot handle future requirements.
Security rules added as comments instead of enforced in code.
Business logic duplicated across frontend, backend, and scripts.
Error handling that hides failures instead of making them observable.
Dependencies added because the agent knew them, not because the project needed them.
A codebase that grows quickly but becomes harder to change every week.

This is not because AI is useless. It is because AI is powerful enough to let people create complexity before they understand the cost of complexity.

Fundamentals matter more, not less

The more capable AI agents become, the more important the fundamentals become.

That sounds counterintuitive. If the agent writes the code, why should a developer understand the basics?

Because someone must know whether the output is correct.

Because someone must notice when the agent solved the wrong problem.

Because someone must decide whether a shortcut is acceptable for a prototype or dangerous for production.

Because someone must be accountable when real users, real money, or real data are involved.

The fundamentals that matter most in the AI era are not just syntax. They are the concepts that help you reason about software.

The fundamentals developers still need

Programming logic

You need to understand conditions, loops, functions, composition, state, side effects, and errors. If you cannot follow the logic, you cannot review the agent's logic.

Data modeling

Most software is a user interface around data. If your data model is wrong, everything above it becomes awkward. AI can generate models quickly, but you need to know whether the relationships, constraints, and naming make sense.

HTTP and APIs

Modern products are built from systems talking to each other. Developers and founders need to understand requests, responses, status codes, authentication, rate limits, webhooks, and failure modes.

Databases

You do not need to be a database administrator to build products, but you need to understand tables, indexes, migrations, transactions, constraints, and why "just add another field" is sometimes not simple.

Testing

AI agents can write tests. They can also write tests that prove very little. You need to understand the difference between testing behavior and testing implementation. A test suite should increase confidence, not create a false sense of safety.

Debugging

Debugging is not only fixing errors. It is forming hypotheses, inspecting evidence, reducing uncertainty, and learning how the system actually behaves. AI can assist, but debugging remains a thinking skill.

Security and privacy basics

AI can accidentally expose data, skip authorization checks, trust user input, or create insecure defaults. If you are building for real users, you need enough security literacy to recognize obvious risks.

Git and collaboration

Agentic workflows produce more changes faster. That makes version control more important. You need to understand diffs, commits, branches, pull requests, rollbacks, and code review hygiene.

Architecture and tradeoffs

Architecture is not drawing boxes. It is choosing where complexity should live. AI can suggest patterns, but it does not know your business priorities unless you tell it, and it may not understand the long-term cost of a decision.

For current developers: your job is changing, not disappearing

If you are already a developer, the best response is not denial and not panic.

Do not compete with AI at typing repetitive code. You will lose, and that is fine. Compete where human engineering judgment matters.

Your advantage is the ability to understand context:

What the user actually needs.
What the business can afford to maintain.
What the system already does.
What must not break.
What can be simplified.
What risks are acceptable.

The strongest developers will use agents aggressively, but they will not outsource their judgment. They will become better at writing specifications, splitting work into safe tasks, reviewing generated code, designing test strategies, and explaining tradeoffs to non-technical people.

The weak version of AI-assisted development is: "Generate this for me."

The strong version is: "Here is the context, here are the constraints, here is the acceptance criteria, here are the tests you must not break, here is the style of the codebase, and here is what I want you to explain before I approve it."

That is agentic engineering as a professional practice.

For people learning development: AI lowers the barrier, not the standard

If you want to become a developer today, you are entering the field at a strange but exciting moment.

On one hand, AI gives you leverage that previous generations did not have. You can ask questions, request examples, generate exercises, get explanations, debug errors, and explore unfamiliar concepts faster than ever.

On the other hand, AI can also let you skip the learning that would make you employable.

If you copy generated code without understanding it, you are not learning development. You are learning dependency. The first time something breaks in a way the agent cannot immediately fix, you will be stuck.

The goal is not to memorize every syntax detail. The goal is to build a mental model of how software works.

Use AI as a tutor:

Ask it to explain code line by line.
Ask why a solution works.
Ask for a simpler version.
Ask for edge cases.
Ask it to quiz you.
Ask it to show a wrong solution and explain why it is wrong.
Rebuild the same thing yourself without copying.

If you are learning, the best question is often not "Can AI build this for me?" It is "Can AI help me understand this deeply enough that I can change it safely?"

For founders: AI agents are leverage, not a replacement for technical literacy

For founders, agentic engineering is genuinely powerful. You can validate ideas faster. You can build landing pages, internal dashboards, prototypes, automation scripts, and early MVPs with a smaller budget. You can test more assumptions before hiring a full team.

That is good.

But founders should be careful with the word "ship." Shipping a prototype is not the same as shipping a reliable product. Shipping to ten friendly testers is not the same as shipping to paying customers. Shipping a demo is not the same as operating software with security, uptime, analytics, backups, and support.

AI agents can help founders move quickly, but founders still need enough technical literacy to ask better questions:

What data are we storing?
Who can access it?
What happens when this fails?
How do we know it failed?
Can we change this later without starting over?
What should be tested before users depend on it?
What is prototype code and what is production code?

You do not need to become a senior engineer to use AI agents well. But if you are building a business on software, you need to understand enough to avoid building your company on fragile assumptions.

A practical agentic engineering workflow

Here is a simple workflow that works for developers, learners, and founders.

1. Start with a short spec

Write what the feature should do, who it is for, and what success looks like. Include what it should not do. A vague prompt creates vague software.

2. Ask for a plan before code

Do not let the agent jump straight into implementation for anything important. Ask it to inspect the codebase and propose a plan first. Review that plan like you would review a junior developer's approach.

3. Make the task smaller

Agents perform better when work is scoped. Instead of "build the whole app," ask for one vertical slice: model, endpoint, UI, test, and docs for one behavior.

4. Define acceptance criteria

Tell the agent how you will judge the work. Good acceptance criteria reduce ambiguity and make review easier.

5. Run tests and inspect the diff

Never trust only the summary. Read the changed files. Check whether the implementation matches the plan. Run the relevant tests. If there are no tests, ask why.

6. Ask for risks

After implementation, ask the agent to list risks, edge cases, and assumptions. This often reveals hidden problems.

7. Keep human accountability

The agent can generate code. It cannot own the consequences. If you merge it, deploy it, or sell it, the responsibility is yours.

A simple checklist before shipping AI-generated code

Before shipping something an AI agent helped build, ask:

Do I understand what changed?
Did I inspect the diff?
Did tests run successfully?
Are the tests meaningful?
Is user input validated?
Is authorization handled correctly?
Are errors visible and recoverable?
Is sensitive data protected?
Is the solution consistent with the existing codebase?
Can we maintain this if the original agent conversation disappears?

If the answer to several of these is "I do not know," you are not ready to ship. You are ready to learn more, reduce scope, or ask for experienced review.

The future developer is not just a coder

The age of AI does not make developers irrelevant. It changes what the word developer means.

A developer used to be someone who could turn requirements into code. Increasingly, a developer is someone who can turn unclear goals into reliable systems, using every tool available, including AI agents.

That requires technical skill. It also requires product thinking, communication, judgment, taste, skepticism, and responsibility.

The people who only know how to type code may struggle. The people who understand software will become more valuable because they can use AI without being fooled by it.

Agentic engineering is not the end of learning to code. It is the end of pretending that code alone is the job.

If you are interested in topics like AI-assisted development, product engineering, agentic workflows, and the future of software teams, subscribe to the Pyango newsletter so we can share new essays, experiments, and practical lessons with you.

And if you want to become a developer in this new AI-native era, take a look at TomorrowDev: https://tomorrowdev.ch

Being a Developer in the Age of AI: Agentic Engineering, Fundamentals, and the End of "Just Coding"

Resources

Latest blogs