Vibe Coding vs Agentic Engineering: How AI Is Changing Software Development

AI-assisted software development is changing how modern software engineers build products. Tools powered by large language models can now generate code, implement features, fix bugs, refactor applications, write tests, and help developers explore technical solutions in a fraction of the time.

But faster code generation does not automatically mean better engineering — and the vibe coding vs agentic engineering debate is really about who keeps control of the system.

I've shipped production apps solo with this engineer-led AI development approach — Astra Chat, MatesLive, and a live fintech product at AmentoTech — so this isn't abstract advice from a content farm. The term "vibe coding" itself was popularized by [EXTERNAL LINK NEEDED: Andrej Karpathy's original vibe coding thread]; what follows is how that idea holds up (and breaks) when you are the one accountable for production.

As AI coding tools become more capable, a new question becomes increasingly important:

How do we use AI to increase development speed without losing control over architecture, code quality, and our understanding of the system?

That question is the heart of vibe coding vs agentic engineering.

---

What Is Vibe Coding?

Vibe coding is an approach where the developer describes what they want to build and allows an AI model to determine much of the implementation.

A typical vibe coding workflow looks like this:

Describe the requirements
        ↓
Ask AI to generate the implementation
        ↓
Run and test the application
        ↓
Find problems
        ↓
Ask AI to fix them
        ↓
Repeat

A more structured version might first ask AI to refine the requirements before implementation:

Requirements
     ↓
AI refinement
     ↓
Implementation
     ↓
Testing
     ↓
Review
     ↓
Fixes
     ↓
Repeat

This approach is extremely useful.

It can be particularly effective for:

• prototypes
• proof-of-concepts
• small applications
• experiments
• internal tools
• simple CRUD applications
• UI experiments
• learning projects

For these types of projects, the speed gained from AI-generated implementation can be enormous.

However, the limitations become more visible as the project grows.

---

How to Avoid the 90% Problem With AI Code

One pattern that can appear during AI-assisted development is what I call the 90% problem.

The first 80–90% of a project can be surprisingly easy.

AI can quickly generate:

• components
• APIs
• database queries
• forms
• authentication flows
• state management
• tests
• documentation
• integrations

Everything seems to move incredibly fast.

Then the project approaches completion.

Suddenly, the remaining work becomes disproportionately difficult.

You start encountering:

• hidden dependencies
• architectural inconsistencies
• duplicated logic
• unexpected side effects
• edge cases
• regressions
• inconsistent abstractions
• difficult debugging
• business-rule conflicts

The problem isn't necessarily that the AI generated bad code.

The deeper problem is context and system understanding.

A software product is more than the files currently visible to an AI.

It also contains:

• business decisions
• architectural intent
• historical constraints
• implicit assumptions
• relationships between modules
• future requirements
• technical trade-offs

When those things aren't explicitly maintained, AI can make locally reasonable decisions that create globally problematic results.

---

What Is Agentic Engineering?

Agentic engineering is a more controlled approach to an AI-assisted software development workflow.

Instead of allowing AI to independently decide what the product should become, the engineer defines the direction and uses AI as an implementation and reasoning partner — an agentic engineering workflow where ownership stays with the human.

The basic principle is:

The engineer owns the decisions. AI accelerates the execution.

A typical workflow can look like:

Engineer defines the goal
        ↓
AI extracts and structures requirements
        ↓
AI identifies missing information
        ↓
AI asks targeted questions
        ↓
Engineer provides the missing context
        ↓
AI creates an implementation plan
        ↓
Engineer reviews and challenges the plan
        ↓
Engineer approves/refines the approach
        ↓
AI implements
        ↓
Engineer verifies the result

The difference isn't simply that the AI is more advanced.

The difference is where responsibility remains.

---

AI Should Not Own the Architecture

One of the most important principles of AI-assisted engineering is maintaining architectural control.

The engineer should provide AI with the architectural boundaries of the project.

This can include:

• database schemas
• data structures
• interfaces
• API contracts
• folder structure
• module boundaries
• state management patterns
• coding conventions
• dependency rules
• technical constraints
• existing abstractions

AI can still propose alternatives.

It can identify potential problems.

It can suggest improvements.

But the engineer should make the final decision.

A useful rule is:

AI can propose. The engineer decides.

---

How to Give AI Persistent Project Context

Another important part of agentic engineering is providing AI with persistent project knowledge — the same practice I outline in more detail in [link to post about my agentic workflow docs setup].

Instead of putting all project knowledge into individual prompts, important decisions can be maintained in project documentation.

For example:

docs/
├── architecture.md
├── product-requirements.md
├── technical-requirements.md
├── database.md
├── api-contracts.md
├── coding-standards.md
└── decisions/
    ├── authentication.md
    ├── state-management.md
    └── payment-architecture.md

These documents can become part of the project's source of truth.

They also provide context to AI coding agents.

When an architectural decision changes, the documentation can change with it.

This creates a much more sustainable AI development workflow than repeatedly explaining the same information through prompts.

---

The Most Dangerous AI Coding Habit

One of the most common mistakes in AI-assisted development is blindly trusting AI's recommendations.

For example, an AI agent might present three possible approaches:

Option A
Option B
Option C

Instead of understanding the trade-offs, the developer asks:

"Which option do you think is best?"

Then accepts the answer.

This seems efficient.

But it gradually transfers engineering decision-making from the developer to the AI.

Over time, AI can start making decisions about:

• architecture
• database design
• libraries
• abstractions
• API contracts
• state management
• error handling
• project structure

The developer becomes an approver rather than an engineer.

That is where the real risk begins.

---

The Knowledge Gap

AI-assisted development can create a dangerous AI coding knowledge gap.

A developer may have contributed thousands of lines of AI-generated code without fully understanding how the system works.

Eventually someone asks:

How does this feature work?

And the developer cannot explain it.

Or someone asks:

Why did we choose this architecture?

And the answer is:

The AI suggested it.

This is a serious engineering problem.

The issue isn't AI-generated code.

The issue is loss of understanding.

A developer should be able to reason about the important parts of the software they are responsible for.

Otherwise, the codebase can gradually accumulate functionality that:

• nobody intentionally designed
• nobody fully understands
• nobody knows why exists
• nobody knows what depends on
• nobody is comfortable changing

This creates technical debt and slows down future development.

---

AI Should Accelerate Engineering, Not Replace It

AI changes where engineers spend their time.

Before AI coding tools became widely available, developers spent a significant amount of time translating technical decisions into code.

With AI, more of that implementation work can be delegated. Treating the model like a junior pair — with clear ownership and review — is one of the most useful AI pair programming best practices I've found. Writers like [EXTERNAL LINK NEEDED: Simon Willison on AI-assisted programming / agents] have documented similar patterns from the practitioner side.

The engineer can spend more time on:

Understanding
     ↓
Designing
     ↓
Reasoning
     ↓
Directing
     ↓
Reviewing
     ↓
Verifying

This doesn't make software engineering knowledge less important.

It makes engineering judgment more important.

The better you understand:

• software architecture
• databases
• APIs
• state management
• testing
• performance
• security
• distributed systems
• debugging

the better you can use AI.

AI amplifies engineering ability.

It doesn't automatically create engineering judgment.

---

How to Use AI for Debugging Without Losing Control

A weak AI-assisted debugging workflow is:

"There is a bug. Fix it."

A stronger workflow starts with understanding the problem.

Step 1: Understand the bug

Identify:

• what is happening
• what should happen
• when it happens
• how to reproduce it
• whether it is deterministic

Step 2: Identify the affected area

Determine:

• relevant modules
• relevant files
• related APIs
• related database operations
• related state

Step 3: Explain the expected behavior

Give AI a precise description of what the system should do.

Step 4: Create an implementation plan

Ask AI to reason about the required changes.

Step 5: AI code review checklist for developers

Challenge the proposed solution before you let AI touch the codebase.

Ask:

• Does this change the existing architecture?
• Could this introduce a regression?
• Is there a simpler approach?
• Does this violate an existing abstraction?
• Are there edge cases?

Step 6: Implement

Once the approach is approved, let AI perform the implementation.

Step 7: Verify

Test the result against the original problem and the implementation plan.

---

How to Use AI for New Features

The same philosophy applies to feature development.

Instead of simply saying:

"Build feature X."

Start by understanding the feature.

A practical workflow is:

Understand the feature
        ↓
Define expected behavior
        ↓
Identify affected modules
        ↓
Identify relevant files
        ↓
Define constraints
        ↓
Create implementation plan
        ↓
Review and challenge the plan
        ↓
Approve
        ↓
Implement
        ↓
Verify

The implementation should be the result of reasoning, not the beginning of it.

---

The Balance Between Control and Speed

AI-assisted development creates two extremes.

Too little AI

If developers insist on manually implementing everything, they may sacrifice significant productivity.

Too much AI

If developers blindly delegate decisions to AI, they can lose control over architecture and accumulate knowledge gaps.

The goal is not maximum AI involvement.

The goal is the right amount of AI involvement.

The balance is:

Control ↔ Speed

We want AI to handle repetitive and mechanical work while the engineer remains responsible for important decisions.

---

Vibe Coding vs Agentic Engineering: Side-by-Side

The distinction can be summarized like this:

Neither approach is universally wrong.

Vibe coding is useful.

But as the complexity of a product increases, maintaining engineering control becomes increasingly important.

---

The Future of Software Development

I don't think the future of software engineering is:

Humans manually write every line of code.

But I also don't think the future is:

AI builds everything while humans blindly approve it.

The more interesting future is somewhere between the two.

Humans will increasingly define:

• intent
• requirements
• architecture
• constraints
• business rules
• technical decisions
• quality standards

AI will increasingly handle:

• implementation
• refactoring
• code generation
• testing
• documentation
• exploration
• repetitive engineering tasks

The engineer becomes increasingly responsible for directing and verifying the system.

---

Learn Software Engineering by Building With AI

There is one more lesson I think is particularly important.

The best way to learn in the AI era is still:

Build.

Build products with AI.

Use AI to implement things that would otherwise take much longer.

Then reason about what was created.

Ask:

• Why was this architecture chosen?
• Why does this abstraction exist?
• What are the trade-offs?
• What happens when this fails?
• How would this behave at scale?
• What would I change?
• Could I explain this implementation to another engineer?

This creates a powerful learning loop:

Build with AI
      ↓
Inspect
      ↓
Reason
      ↓
Question
      ↓
Learn
      ↓
Build again

AI gives developers an incredible opportunity to experiment and build faster than ever.

We should take advantage of it.

But we should not outsource our understanding to it.

---

Conclusion

AI is changing software development.

The important question is no longer simply:

"Can AI write this code?"

It clearly can.

The more important questions are:

"Does AI understand why we're building this?"

"Do I understand what AI built?"

"Do I still control the architecture?"

"Can I explain the decisions behind the system?"

I ask myself those questions on every production ship — whether that is a chat client, a social/commerce ecosystem, or fintech work where mistakes are expensive. Vibe coding vs agentic engineering is not a branding exercise for me; it is how I decide when to explore and when to lock the boundaries.

The future belongs neither entirely to manual coding nor entirely to autonomous AI development.

It belongs to engineers who can combine technical knowledge, architectural judgment, and AI-assisted execution.

Use AI to move faster.

Use your engineering knowledge to decide where to go.

And most importantly:

Never trade speed for loss of control.