There is a strange conversation happening across the technology industry.

Ask a Data Analyst about AI and you might hear:

“AI can write SQL now. Maybe companies won’t need as many analysts.”

Ask a Data Engineer:

“Connectors are automated. AI can write transformations and build pipelines. Maybe traditional data engineering shrinks.”

Ask a Software Engineer:

“Coding agents can implement features, run tests and fix bugs.”

Ask a Business Analyst:

“AI can listen to meetings and generate requirements.”

Ask a Project Manager:

“AI can create Jira tickets, summarize meetings, track deadlines and generate project plans.”

Follow every one of these arguments to its logical conclusion and you arrive somewhere slightly ridiculous:

The CEO explains the objective. AI gathers the requirements. AI creates the project. AI writes the tickets. AI builds the pipelines. AI analyzes the data. AI writes the software. AI tests it. AI deploys it. AI monitors everything.

Company complete.

Except, of course, real organizations don’t work like that.

And understanding why tells us much more about the future of data and technology jobs than another prediction about whether AI will “replace” a particular profession.

AI really is automating the work

We shouldn’t pretend otherwise.

This isn’t 2023 anymore.

AI is increasingly capable of generating SQL, writing transformations, documenting models, creating tests, exploring repositories, modifying multiple files, debugging failures and completing increasingly complex development tasks.

The interesting debate is therefore no longer:

“Can AI write SQL?”

Of course it can.

Or:

“Can AI create a data pipeline?”

Increasingly, yes.

The more important question is:

How much of a job is actually the execution of a clearly specified task?

That’s where things become complicated.

1. The Data Engineer

Consider the traditional data pipeline:

Source → Ingestion → Warehouse → Transformation → Data Model → BI

A surprising amount of the mechanical work involved can already be accelerated or automated.

Give an AI system appropriate access and context and it can help generate ingestion code, SQL transformations, documentation, tests, monitoring logic and debugging suggestions.

So why have Data Engineers?

Because moving data isn’t the entirety of data engineering.

Imagine an AI-generated pipeline works perfectly 99% of the time.

Then an upstream API changes its schema. Or events arrive several hours late. Or retries create duplicate transactions. Or personally identifiable information unexpectedly appears in a downstream table. Or the warehouse bill suddenly triples. Or an apparently harmless transformation changes the historical definition of revenue.

Writing the pipeline was the easy part.

Someone still needs to determine:

• how reliable the system needs to be;
• what happens when it fails;
• how data contracts should work;
• which systems should have access;
• how infrastructure should scale;
• how failures are recovered;
• and who ultimately owns the system.

AI therefore doesn’t necessarily eliminate Data Engineering.

It changes where Data Engineers create value.

And there is an interesting paradox here:

The more AI systems consume organizational data, the more important reliable data infrastructure becomes.

2. The Analytics Engineer

AI can write SQL. It can generate dbt models. It can create YAML. It can suggest tests. It can document models.

So perhaps Analytics Engineering disappears too?

Again, consider what happens when we ask a deceptively simple question:

What is revenue?

One company might have several legitimate answers.

Gross transaction value? Net revenue? Before refunds? After refunds? Including tax? Excluding tax? Using order date, payment date or settlement date? What exchange rate should be used for international transactions?

AI can implement any of those definitions.

Very quickly.

That’s exactly the problem.

The difficult part wasn’t typing the SQL. The difficult part was getting Finance, Product, Operations and Marketing to agree on what the number represents.

The same problem appears with Active Customer.

Marketing might define one as someone who signed up. Product might require activity within 30 days. Finance might require a completed payment. Operations might require a completed transaction.

All four definitions could produce technically correct SQL.

Only one may be appropriate for a particular business decision.

That’s why the future Analytics Engineer becomes increasingly responsible for something much more valuable than SQL:

AI can generate transformations.

Organizations still need someone to ensure that fifty dashboards — and eventually fifty AI agents — mean the same thing when they say “customer.”

3. The Data Analyst

This is perhaps the role receiving the most obvious pressure.

Ask:

“Show monthly revenue by country.”

AI can probably generate the query and visualization.

Ask:

“Which countries declined last month?”

It can identify them.

Ask:

“Summarize the dashboard.”

It can do that too.

So why employ analysts?

Because those examples contain something unrealistic:

someone already asked the correct question.

Real analytical work often begins with something like:

“Orders look bad. Can you figure out what’s happening?”

Now the analyst has to decide what “bad” means.

Orders? Revenue? Customers? Conversion? Frequency? Retention? AOV? One city? One acquisition channel? New customers? Existing customers?

The first analytical skill isn’t SQL.

It’s decomposition.

And then comes interpretation.

Suppose DAU increased 30%. Great news? Maybe. What if acquisition spending doubled? What if Day-7 retention fell? What if existing users are leaving while paid acquisition continuously replaces them?

The dashboard isn’t technically wrong.

The conclusion is.

Or suppose ROAS increases dramatically. Should Marketing increase spending? Maybe attribution changed. Maybe organic conversions are being credited to paid campaigns. Maybe a promotion increased conversion temporarily. Maybe the customers acquired through that campaign have terrible retention.

Generating a chart is becoming cheap.

Knowing whether the chart should change a decision remains valuable.

The analyst of the future therefore spends less time extracting CSVs, fixing repetitive queries and manually assembling charts — and more time investigating, questioning, experimenting, interpreting and recommending.

This does create a real threat.

If an analyst’s entire job is:

Receive perfectly defined request → write query → build chart → send chart

then a large portion of that workflow is absolutely vulnerable to automation.

The answer isn’t to compete with AI at typing SQL faster.

It’s to become responsible for a larger portion of the decision.

4. The Business Analyst

Business Analysts appear vulnerable for a similar reason.

Modern AI can turn conversations into structured notes. It can summarize meetings. Generate requirements. Write user stories. Suggest acceptance criteria. Create process documentation.

So why have Business Analysts?

Because requirements aren’t simply information waiting to be transcribed.

Stakeholders routinely ask for solutions instead of describing problems.

“We need a dashboard.”

Maybe they don’t.

“Add another approval step.”

Maybe the existing process is the problem.

“Automate this report.”

Maybe nobody should be using that report anymore.

A strong Business Analyst asks:

What are we actually trying to achieve?

Then comes the organizational problem.

Finance wants control. Sales wants speed. Operations wants flexibility. Legal wants compliance. Customers want simplicity. Engineering wants maintainability.

Those aren’t missing requirements.

They’re conflicting incentives.

AI can document the conflict beautifully.

Someone still needs to help the organization resolve it.

So Business Analysis moves away from being a documentation factory and toward discovery, facilitation, process design and decision clarity.

The repetitive tasks shrink. The ambiguous tasks become the job.

5. The Project Manager

A significant amount of visible project-management administration is automatable.

Meeting summaries. Status reports. Ticket generation. Sprint documentation. Dependency tracking. Reminder messages. Project-plan drafts. Risk registers.

If that’s the Project Manager’s entire contribution, then yes — the role has a problem.

But imagine a project where Engineering estimates six weeks. Sales already promised the customer two weeks. Legal discovers a compliance issue. Design changes the user journey. A dependency owned by another team slips. Leadership adds another “critical” feature.

Now ask AI to “manage the project.”

It can update the schedule.

That’s not the problem.

The organization disagrees with itself.

Someone has to negotiate priorities. Someone has to escalate. Someone has to communicate trade-offs. Someone has to decide what gets cut. Someone has to get people to commit.

Project management is often less about maintaining the plan and more about managing everything that destroys the plan.

AI can identify exceptions extremely well.

Humans still have to resolve many of them.

Less Jira administration. More prioritization, facilitation, negotiation, risk management and organizational coordination.

6. The Software Engineer

AI coding agents have moved far beyond autocomplete.

They can increasingly inspect repositories, modify multiple files, execute commands, run tests, debug problems and prepare changes for human review.

So perhaps Software Engineers disappear and the PM simply manages AI agents?

But again, writing code is only one component of engineering.

Imagine an AI agent produces a feature and every automated test passes.

Should you deploy it?

What if the tests don’t cover the actual failure mode? What happens at 100 times the current traffic? Does the database migration lock a critical table? Could the change expose sensitive data? Will an older service break? Can the deployment be rolled back safely? Does this implementation create architectural debt that becomes expensive six months later?

Software Engineering increasingly becomes less about manually producing every line of code and more about specifying, designing, reviewing, integrating and owning systems.

That doesn’t mean coding disappears.

It means the amount of code one engineer can produce and supervise increases dramatically.

So… why not CEO → AI → Company?

If Data Engineering can be automated… and Analytics Engineering can be automated… and Analysis can be automated… and Business Analysis can be automated… and Project Management can be automated… and Software Engineering can be automated… why not simply connect everything together?

Because we’ve made one fundamental mistake.

A job isn’t a single task.

It’s a collection of:

AI is becoming extraordinarily capable at absorbing tasks.

But the other components don’t disappear at the same speed.

And this leads to what I think is the more realistic transformation of technology organizations.

AI won’t only replace roles. It will blur them.

Historically, organizations separated work partly because execution was expensive.

The analyst needed engineering to prepare data. The Business Analyst needed engineering to prototype. The PM needed developers to estimate implementation. The developer needed someone else to analyze production data.

AI reduces some of those barriers.

An analyst can now build lightweight data pipelines. A Data Engineer can perform exploratory analysis. A Business Analyst can prototype an application. A Product Manager can interrogate data. A Software Engineer can generate analytical models.

The boundaries between professions become less rigid.

That’s potentially a much bigger change than simply eliminating one profession.

The future may contain fewer narrow specialists

Consider two analysts.

Analyst A

Can write SQL. Can build dashboards. Waits for requirements. Waits for Engineering when data isn’t available. Produces exactly what was requested.

Analyst B

Understands the business. Can frame ambiguous problems. Uses AI to write SQL faster. Can modify a dbt model when necessary. Can build a lightweight pipeline. Understands experimentation. Can prototype. Can communicate with Engineering. Can turn analysis into a business recommendation.

If AI makes both analysts twice as productive, it doesn’t necessarily protect Analyst A.

It may make Analyst B dramatically more powerful.

And the same logic applies to almost every profession discussed above.

The real disruption: 10 responsibilities, fewer boundaries

People often imagine AI transformation as:

10 employees → 1 AI

I suspect many organizations will experience something more subtle:

10 narrowly separated responsibilities → fewer people with broader capabilities + AI

One person may operate across areas that previously required several handoffs.

That doesn’t mean expertise stops mattering.

Quite the opposite.

Deep expertise becomes important because AI dramatically increases the amount of work an individual can attempt.

Someone still needs to recognize when the machine is confidently wrong.

Context becomes more valuable as execution becomes cheaper

This may be the most important shift.

When producing SQL was expensive, SQL skill was scarce. When producing software was expensive, coding capacity was scarce. When producing reports was expensive, dashboard-building capacity was scarce.

AI makes execution cheaper.

What becomes scarce instead?

Knowing:

What should we build?

Why?

Which metric matters?

Which constraint matters?

What does this data actually represent?

Which trade-off is acceptable?

What could go wrong?

Who is accountable?

When should we ignore the AI?

In other words:

context and judgment.

What should data professionals do?

I don’t think the answer is “learn prompt engineering.”

Prompts will increasingly become an ordinary interface.

Instead, build three things.

1. Deep domain knowledge

Understand how businesses actually work: revenue, customers, operations, marketing, products and finance.

The better you understand the domain, the better you can recognize when an AI-generated answer makes no sense.

2. Adjacent technical capability

Analysts should understand data modeling. Analytics Engineers should understand infrastructure. Data Engineers should understand business metrics. Business Analysts should become comfortable with data. PMs should become comfortable prototyping. Engineers should understand product and business context.

You don’t have to become an expert in everything.

But the walls between roles are becoming lower.

3. Judgment

This is harder to put on a certification.

Learn to question assumptions. Understand trade-offs. Recognize bad metrics. Know when correlation is misleading. Understand how systems fail. Know when the technically elegant solution is the wrong business solution.

And most importantly:

Learn to ask better questions.

Use AI aggressively. Don’t outsource your thinking.

There is another mistake we can make here.

Being skeptical about complete job replacement shouldn’t become an excuse to avoid AI.

That would be equally dangerous.

If AI can write the first version of your SQL, use it. If it can generate documentation, use it. If it can investigate a failing pipeline, use it. If it can create a prototype, use it. If it can summarize a meeting, use it. If it can automate repetitive analysis, use it.

The goal isn’t to prove that humans can still manually perform every task.

The goal is to move your attention toward the parts where your judgment creates the most value.

The question isn’t whether AI replaces your job

Jobs have always changed when the economics of execution changed.

AI is accelerating that process across many professions simultaneously.

Some positions will shrink. Some responsibilities will disappear. Some teams will become smaller. New roles will appear. Existing roles will absorb responsibilities from neighboring disciplines. And individuals who refuse to adapt will face genuine pressure.

But asking:

“Will AI replace Data Analysts?”

is probably too simplistic.

A better question is:

“Which parts of being a Data Analyst are becoming nearly free — and what becomes valuable when they do?”

Ask the same question for Data Engineering. Analytics Engineering. Business Analysis. Project Management. Software Engineering.

That’s where the interesting answers begin.

My prediction

AI won’t simply erase the technology org chart.

It will compress it.

The boundaries between jobs will become less rigid. Routine execution will become cheaper. People will operate across larger areas. Small teams will accomplish things that previously required much larger teams.

And the value of context, judgment, ownership and domain expertise will increase.

Which leaves us with a slightly different warning than:

“AI is coming for your job.”

The warning I’d pay attention to is this:

That’s the career challenge worth preparing for.