I have been using AI in my day-to-day work long enough now that it no longer feels like a novelty. It feels like a tool. A powerful one — but still a tool.
One of the first places it became genuinely useful for me was in helping develop and debug SQL queries and schemas for a Retool-based low-code application we were building for a real estate services company.
The system was not trivial.
It had:
- Multiple operational workflows (orders, fulfillment, payouts, reporting)
- A growing PostgreSQL schema
- Business logic spread across Retool, the database, and integrations
- And real financial and operational consequences if anything was wrong
This was not toy SQL. It was production logic.
And AI — specifically ChatGPT — was surprisingly good at it.
The good: speed, fluency, and breadth
What immediately stood out to me was how fluent it was with SQL.
Not just syntax — but structure, patterns, and even database-specific nuance.
It understood:
- Common Table Expressions
- Window functions
- Grouping edge cases
- Join cardinality problems
- The difference between filtering before vs after aggregation
- How Postgres treats NULLs, timestamps, and type coercion
It could:
- Rewrite a messy query into something more readable
- Spot obvious logical mistakes quickly
- Suggest alternate query structures
- Help reason about data shape and aggregation levels
The speed was the most noticeable thing.
Things that would normally take me:
- 15 minutes to reason through
- 10 minutes to write
- 10 minutes to sanity-check
...could often be reduced to a short back-and-forth.
In terms of raw mechanical capability, it often felt on par with a strong senior engineer or DBA — especially for well-formed, localized problems.
That is genuinely impressive.
And it is genuinely useful.
The problem: hallucination and false confidence
Where things started to break down was exactly where I expected them to: complexity and uncertainty.
As the system grew more complex, and as the schema evolved, ChatGPT started to do something subtle but dangerous.
It began to confidently reference things that did not exist.
Not in a dramatic way.
In a very plausible way.
It would:
- Reference columns that sounded right but were not there
- Assume tables had relationships they did not
- Invent fields that should exist in a well-designed system
- Confidently build logic on top of those invented assumptions
And it would not tell you it was guessing.
It would just proceed.
That is the core danger.
Not that it is wrong.
But that it is wrong in a way that looks right.
And when you are working in financial, operational, or production systems, looks right is not good enough.
How I learned to work with it
Over time, I stopped treating ChatGPT like an engineer and started treating it like a very powerful but unreliable assistant.
That changed how I used it.
I stopped asking:
Write this entire query.
And started asking:
- Help me think through this.
- What are the edge cases here?
- What would be a clean structure for this?
- Is there a simpler way to express this?
- Does this logic have any obvious flaws?
I also got stricter about:
- Explicitly pasting schema
- Explicitly naming columns
- Explicitly defining assumptions
And I got very disciplined about verification.
I never trusted output blindly.
I always ran it.
I always tested it.
I always sanity-checked it against reality.
That is not because I distrust the tool.
It is because I respect the cost of being wrong.
Forcing decomposition and reconciliation
One pattern I noticed very quickly is that AI tends to try to solve the entire problem in one go.
It will happily generate a large, monolithic solution — a giant query, a complex pipeline, or an end-to-end flow — even when the problem is poorly understood or still evolving.
That is almost always the wrong move.
So I started forcing the opposite behavior.
Instead of letting it build the whole thing, I would direct it to:
- Break the problem into small, easily verifiable pieces
- Solve each piece independently
- Validate each piece against reality
- And only then compose them into a larger system
For example, instead of building one big reporting query, I would have it:
- First define the correct base dataset
- Then validate row counts and filters
- Then validate aggregations in isolation
- Then reconcile results against existing reports
- Then check edge cases and anomalies
I would often ask it to help me manually reconcile different reports and data sources — not to trust one output, but to cross-check them against each other.
That process matters.
Because correctness in complex systems rarely comes from one clever solution.
It comes from convergence — when multiple independent views agree.
A pattern I now trust
The pattern that works for me looks like this:
- Define the problem clearly.
- Define the schema explicitly.
- Break the problem into small pieces.
- Ask the AI to reason, not just generate.
- Reconcile outputs against reality and against each other.
- Only then compose the full solution.
Used this way, it is incredibly valuable.
Used casually, it is dangerous.