DEV Community: Ravi Kiran Pagidi

Vibe Coding vs Engineering: Where I Draw the Line

Ravi Kiran Pagidi — Sat, 09 May 2026 04:23:17 +0000

AI has changed how fast we can write code. A decent prompt can now give you a working script, a UI stub, a FastAPI route, or even a rough end-to-end feature in minutes.

That is genuinely useful. I use AI coding tools all the time. But I also think a lot of teams are starting to confuse generated code with engineered software, and those are not the same thing.

Vibe coding is not the problem. Treating vibe-coded output like production-ready engineering is the problem.

What I Mean by Vibe Coding

When I say vibe coding, I mean the style of working where you prompt an AI tool, accept most of what it gives you, run it, patch a couple of errors, and keep moving.

That works surprisingly well for:

Prototypes
Proof of concepts
Learning a new library
UI experiments
Throwaway scripts
Hackathons
Brainstorming implementation options

I do this myself. If I need to test an idea quickly, I do not want to spend an hour polishing structure before I know the idea is even worth keeping.

Here is a totally reasonable example:

import pandas as pd

df = pd.read_csv("orders.csv")

summary = (
    df.groupby("status")
      .agg(order_count=("order_id", "count"),
           total_amount=("amount", "sum"))
      .reset_index()
)

print(summary)

For quick exploration, this is fine. It answers a question fast. It helps you inspect data. It may be exactly what you need for ten minutes of analysis.

But this is not engineering yet.

Where Vibe Coding Works Well

Vibe coding shines when the cost of failure is low and the main goal is speed.

A few examples:

You want to sanity-check a CSV before loading it into a warehouse.
You want to test a new SDK without reading the whole documentation.
You need a quick internal demo for a product idea.
You are exploring three different implementation patterns and want rough drafts first.

In those moments, AI is a force multiplier. It cuts blank-page time. It helps you learn by doing. It gives you something concrete to react to.

That is valuable. I just do not confuse that value with production readiness.

Where Engineering Begins

Engineering starts when the code has to be trusted.

Trusted by other developers. Trusted by downstream systems. Trusted by customers, auditors, operators, managers, and business processes that assume the software will behave correctly even when inputs are messy and real life is inconvenient.

That is the line I draw.

Once code crosses that line, the job changes. Now I care about:

Clear requirements
Edge cases
Input validation
Error handling
Logging
Testing
Deployment
Ownership
Security
Performance
Long-term maintainability

This is where senior engineering judgment matters. The real value is not typing faster. It is knowing what should be built, what should not be built, what can fail, what needs monitoring, and what needs to be explained clearly to the team.

Same Example, But Engineered

Here is the same CSV example with a bit more engineering discipline:

import logging
from pathlib import Path
import pandas as pd

REQUIRED_COLUMNS = {"order_id", "status", "amount"}

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)


def load_orders(file_path: str) -> pd.DataFrame:
    path = Path(file_path)

    if not path.exists():
        raise FileNotFoundError(f"Input file not found: {file_path}")

    df = pd.read_csv(path)

    missing_columns = REQUIRED_COLUMNS - set(df.columns)
    if missing_columns:
        raise ValueError(f"Missing required columns: {missing_columns}")

    if df["amount"].isnull().any():
        raise ValueError("Amount column contains null values")

    return df


def summarize_orders(df: pd.DataFrame) -> pd.DataFrame:
    return (
        df.groupby("status")
          .agg(
              order_count=("order_id", "count"),
              total_amount=("amount", "sum")
          )
          .reset_index()
    )


def main() -> None:
    try:
        logger.info("Loading order data")
        orders = load_orders("orders.csv")

        logger.info("Generating order summary")
        summary = summarize_orders(orders)

        logger.info("Summary generated successfully")
        print(summary)

    except Exception as exc:
        logger.exception("Failed to process order data")
        raise exc


if __name__ == "__main__":
    main()

The first version answers a question. The second version is starting to behave like software someone else can depend on.

It is still small, but it has shape. You can test summarize_orders() independently. You can fail early on bad input. You get logs. You have a place to extend behavior without turning the whole file into a fragile pile of assumptions.

That is the difference. Engineering is not just making code work. It is making code dependable.

The Line I Draw

Here is the simplest way I explain it:

Area	Vibe Coding	Engineering
Goal	Make it work	Make it reliable
Speed	Very fast	Controlled speed
Validation	Manual testing	Automated tests/checks
Ownership	Prompt-driven	Design-driven
Failure handling	Often missing	Expected and handled
Security	Often overlooked	Designed in
Documentation	Minimal	Useful and intentional
Maintainability	Secondary	Core requirement

If I am building a quick script for myself, I am comfortable staying on the left.

If the code will live beyond today, touch production data, support a customer workflow, or wake somebody up at 2 a.m., I need the right side of that table.

AI Agents Make This More Important

The line gets even more important with agentic coding tools.

An AI agent does not just suggest one function anymore. It can modify multiple files, add dependencies, generate tests, update configs, write migrations, and run commands. That is powerful, but it also means mistakes spread faster.

When an agent makes changes, I review at least these things:

Generated diffs, especially across multiple files
New dependencies and their security or maintenance cost
Security-sensitive logic
Hidden assumptions in config or environment handling
Tests that only cover the happy path

The danger is not that the AI writes bad code every time. The danger is that it often writes code that looks complete before it is actually safe.

Example: AI-Generated API Endpoint

This is the kind of endpoint an AI tool can generate in seconds:

from fastapi import FastAPI

app = FastAPI()

@app.get("/customer/{customer_id}")
def get_customer(customer_id: int):
    return {"customer_id": customer_id, "name": "Test Customer"}

For a mock demo, that is fine.

For a real system, I immediately start asking harder questions:

Who is allowed to access this endpoint?
Where does the data come from?
What happens if the customer does not exist?
Are requests logged safely?
Are we leaking private information?
Do we need rate limiting?
How is this monitored in production?
What is the validation story beyond type hints?

Instead of pretending the first draft is enough, I use a checklist:

Authentication
Authorization
Data access layer
Error handling
Structured logging
Request and response validation
Rate limiting
Privacy controls
Monitoring and alerting

That checklist is engineering. The generated route is just a starting point.

Practical Rules I Follow

These are the rules I keep coming back to:

I use AI to accelerate implementation, not replace thinking.
I do not accept security-sensitive code without review.
I ask AI to explain tradeoffs, not just generate code.
I write or review tests myself.
I treat generated code as a draft.
I check dependencies before adding them.
I verify edge cases.
I do not let confident explanations hide real complexity.

The senior engineer advantage is not raw typing speed anymore. It is judgment under ambiguity.

Good Prompts Engineers Should Use

Most bad outcomes start with lazy prompts and even lazier review. Better prompts help, especially when they force the model to think about failure.

A few prompts I actually find useful:

Review this code for edge cases, security risks, and production-readiness issues.

What assumptions does this implementation make, and which of them are risky?

Generate unit tests for success, failure, boundary, and invalid input scenarios.

Refactor this code for readability, testability, and maintainability without changing behavior.

Explain what could go wrong if this code runs in production at scale.

These prompts do not remove the need for engineering judgment. They just make AI more useful to an engineer who is already thinking like one.

Closing

Vibe coding is a great starting point. I use it often, and I think engineers who ignore AI tools are making life harder than it needs to be.

But software becomes valuable when people can trust it, and trust does not come from a convincing code generation. It comes from engineering discipline.

AI can absolutely make good engineers faster. It does not remove the need for judgment, accountability, or careful design. If anything, it makes those things more important.

The future does not belong to the people who can prompt the fastest. It belongs to the engineers who can combine AI speed with production discipline.

Using Databricks Genie for Natural Language Querying on Semantic Models

Ravi Kiran Pagidi — Sun, 26 Apr 2026 01:52:49 +0000

Overview

Databricks Genie is designed to let business users ask questions in plain language and receive answers grounded in governed enterprise data instead of writing SQL themselves. In practical terms, it acts as a conversational layer on top of curated datasets, AI and BI assets, and business context so that end users can explore data using familiar business language.

For organizations that already invest in semantic modelling, Genie becomes more valuable because the quality of answers depends heavily on how well the underlying data model captures business definitions, relationships, trusted metrics, and approved terminology. This means Genie is not just a chatbot for data access. It is a governed analytics interface whose success depends on semantic clarity and disciplined implementation.

What Genie Means for End Users

For end users, the biggest attraction is simplicity. A sales manager can ask a question such as monthly pipeline by region, a finance analyst can ask about margin trends, and an operations lead can ask about delayed orders, all without remembering schema names or joins. This lowers the dependence on technical teams for routine analytical questions and improves access to data across non technical functions.

Genie spaces are curated environments where data, instructions, examples, and business guidance are organized for a specific domain or use case. When curated properly, these spaces help the system interpret user intent more accurately because the model is given a narrower and more meaningful context instead of being exposed to an unbounded set of tables and terms.

Why the Semantic Model Matters

A semantic model gives business meaning to raw data. It defines entities, dimensions, measures, joins, naming conventions, and approved definitions so that end users do not need to understand warehouse level complexity in order to ask useful questions. Without this layer, natural language querying can become inconsistent because the same business term may map to multiple tables, multiple calculation logics, or even conflicting departmental definitions.

This is where Genie and the semantic layer work together. Genie provides the conversational interface, while the semantic model provides the business truth that guides interpretation. If the semantic model is mature, Genie can produce more trustworthy results. If the semantic model is weak, Genie may still respond fluently, but the underlying answer quality may not meet business expectations.

Typical Architecture

A common implementation starts with data in the Lakehouse, followed by curated datasets or governed tables, then semantic definitions, and finally a Genie space configured for a specific business audience. The Genie space usually includes selected datasets, example questions, instructions, metadata, and governance controls that help align user questions with business intent.

In a mature enterprise setup, this architecture also includes access control, certified metrics, monitoring, and periodic review by data owners. The goal is not only to answer questions but to ensure that answers are secure, repeatable, and aligned with organizational definitions of revenue, cost, customer, product, or risk.

Implementation Approach

A successful Genie rollout generally works best when treated as a product, not as a one time feature deployment. The strongest implementations start with one domain such as sales, finance, supply chain, or customer support, where business terms are already reasonably well defined and usage demand is high.

A practical implementation sequence is as follows:

Identify a focused business domain and nominate data owners, semantic owners, and end user champions.
Curate trusted tables or datasets and remove ambiguous or redundant data sources from the user facing scope.
Define the semantic model carefully, including approved metrics, dimensions, hierarchies, synonyms, and join logic.
Configure the Genie space with instructions, sample prompts, and domain specific vocabulary so the system learns how users naturally phrase questions.
Test with real business questions, especially edge cases, vague wording, and competing definitions such as booked revenue versus recognized revenue.
Roll out in phases, observe usage patterns, collect failed questions, and continuously refine the semantic layer and Genie guidance.

This phased model reduces risk because it acknowledges that adoption problems are rarely just technical. Most failures come from weak metric definitions, missing governance, poor testing, or unrealistic assumptions that natural language alone can fix broken data foundations.

Benefits and Strengths

The first major benefit is accessibility. Genie makes analytics more approachable for users who understand the business but do not know SQL, dashboards, or table structures. This expands data usage beyond specialist analysts and helps teams ask more follow up questions in the moment when decisions are being made.

The second benefit is speed. Instead of waiting for a dashboard update or requesting a custom query, users can phrase a question directly and receive a response quickly within a governed environment. For recurring business reviews, this can reduce friction and support a more self service analytics culture.

The third benefit is alignment with governed analytics. Because Genie is intended to work with curated assets and structured business context, it can support more reliable answers than a generic large language model pointed at raw data with no semantic grounding. This is especially important in enterprises where consistent KPI definitions matter more than conversational novelty.

Limitations

Genie is powerful, but it is not a substitute for strong data management. If source data is messy, inconsistent, or poorly documented, the user experience will appear intelligent on the surface while still producing answers that can be incomplete, confusing, or misaligned with business logic. Natural language interfaces reduce technical friction, but they do not remove the need for disciplined modelling and governance.

Another limitation is ambiguity in human language. End users often ask incomplete questions such as top customers last quarter or compare performance across teams, without defining which metric, geography, calendar, or business rule should be used. Even with a strong semantic model, these questions may still require clarification, curated examples, or tighter domain boundaries to avoid incorrect interpretation.

There are also scope limitations. Genie works best in curated domains where the data landscape is intentionally narrowed and business concepts are stable. It is less effective when users expect it to reason across every table in the enterprise, resolve all semantic conflicts automatically, or replace expert analysts for complex, cross functional, or highly customized investigation.

Trade Offs

The core trade off is between flexibility and control. If a Genie space exposes too much data and too many definitions, users may gain freedom but answer quality can fall because ambiguity rises. If the space is tightly curated, accuracy usually improves, but some users may feel constrained because they cannot explore every possible angle.

There is also a trade off between speed of deployment and semantic quality. A fast rollout can create enthusiasm, but if measures, joins, and synonyms are not properly governed, trust can erode quickly once users find inconsistent answers. A slower rollout with rigorous curation usually produces better adoption over time because it protects credibility from the start.

A further trade off appears between self service and expert oversight. Genie can reduce dependency on analysts for routine questions, but organizations still need analysts and data stewards for model design, exception handling, validation, and advanced analytical work. In other words, Genie shifts the role of analytics teams rather than eliminating it.

Pros and Challenges

Aspect	Positive Side	Challenge Side
User Experience	Users can ask questions in business language and get faster access to insights	Vague or overloaded wording can still lead to misinterpretation
Governance	Curated spaces and governed assets improve trust and consistency	Governance requires continuous ownership and effort
Adoption	Non technical users can engage with data more confidently	Adoption drops if answers are inconsistent even a few times
Scale	Reusable semantic structures can support wider business usage	Broad enterprise scope increases ambiguity and maintenance burden
Productivity	Analysts spend less time on repetitive questions	Analysts still need to maintain definitions, test outputs, and handle exceptions

Where It Fits Well

Genie fits especially well in domains with recurring business questions, stable metrics, and a clear owner for data quality and definitions. Typical examples include sales pipeline reviews, finance variance analysis, service performance monitoring, retail demand tracking, and executive KPI exploration where business users repeatedly ask similar questions in slightly different forms.

It is also useful in organizations trying to increase data literacy without forcing every user to learn dashboard design or SQL. When paired with a clean semantic foundation, Genie can become a practical bridge between enterprise data systems and business decision makers.

Where Caution Is Needed

Caution is necessary in environments where core business definitions are still contested, data quality is weak, or source systems change frequently without governance. In such cases, a natural language layer can expose confusion faster rather than solve it, because users will discover conflicting answers through conversation.

It is also risky to position Genie as a universal replacement for dashboards, SQL, or analysts. For exploratory work that requires complex statistical reasoning, unusual joins, specialized logic, or detailed forensic analysis, traditional analytics methods still remain important.

Practical Recommendations

Organizations should begin with a narrow, high value use case and define success in business terms such as reduced analyst tickets, faster access to recurring metrics, improved executive self service, or higher adoption among non technical teams. A carefully scoped launch creates a better signal of real value than a wide launch that mixes mature and immature domains.

It is equally important to invest in semantic quality before promoting the conversational interface. Good synonyms, approved definitions, example questions, and ongoing feedback loops usually matter more than flashy demonstrations. The best results come when business teams, data teams, and platform teams jointly treat Genie as a governed analytical product rather than an AI experiment.

Final View

Databricks Genie can be a strong interface for natural language querying by end users when it is built on a reliable semantic model, curated business context, and disciplined governance. Its real value lies in making governed analytics more accessible, not in bypassing the need for modelling, data stewardship, or analytical thinking.

For most enterprises, the question is not whether Genie can answer questions in natural language. The more important question is whether the organization has built enough semantic clarity and operational ownership to make those answers trustworthy at scale.