How to be a data scientist in 2026 (and beyond)

The answer is not vibe coding

A data scientist wears many hats. Image generated by Nano Banana

In 2012, Harvard Business Review wrote an article acclaiming the data scientist as the sexiest job in the 21st century. Since then many have aspired to break into the field, but the nature of a data scientist has changed.

Look into job descriptions across the board and you’ll realize a few things:

1. Most require generative AI expertise. Specifically, how to build agentic applications.
2. Some (actually many) jobs require languages and tools that traditionally had nothing to do with data science — like Kubernetes and full stack development skills — React.js, TypeScript for frontend web development. Something I never thought would be asked of a data scientist.

The lines between frontend, backend, data, software, and DevOps engineers and roles like data scientists, AI engineers, and MLOps engineers are becoming increasingly blurred.

So what exactly is happening?

The emergence of generative AI is the reason

When ChatGPT came out in end 2022, the trajectory of AI accelerated dramatically, changing the way we work and live.

In my opinion (feel free to disagree):

• 2023 is the year of retrieval augmented generation (RAG) chatbots.

People quickly discovered that chatbots hallucinated easily, so grounding them with retrieved knowledge became essential. This also gave birth to an entire ecosystem of vector databases.

• 2024 is the year of agents and multi-agent systems and how to orchestrate them.

It was no longer just LangChain and LangGraph. Developers started running into real pain points, and new frameworks such as LlamaIndex, Autogen, CrewAI, and Agno emerged with their own approaches to agent orchestration. I’ve written about most of these frameworks myself.

Prompt engineering slowly fell out of fashion as developers discovered it was easier to orchestrate LLMs using workflows.

• 2025 is the year of protocols — model context protocol, agent-to-agent protocols (A2A), etc., and DeepSeek.

Model Context Protocol, agent-to-agent communication, and other interoperability standards began appearing. The key idea was simple: agents built using different frameworks should still be able to communicate with each other. And agents should be able to connect and use any tool.

Existing frameworks adapted, and new ones emerged — ADK, Pydantic AI, and many others.

Around the same time, DeepSeek released its GRPO training recipe, which effectively democratized the training of reasoning models for anyone with access to a GPU.

Wall Street reacted with a frenzy of short selling.

• 2026 is starting to look like the year of copilots.

Tools like Claude Code, OpenAI’s Codex, Gemini CLI, OpenCode, and OpenClaw have made enormous waves. Several companies — including Anthropic and OpenAI now claim that generative AI writes and ships most of their code.

The uncomfortable reality

Has generative AI improved the lives of the masses?

Not everyone would agree.

Fears of being replaced by AI remain widespread. Ironically, the first people to feel that pressure were data scientists and software engineers themselves. Since 2024, mass layoffs have affected many talented engineers. You probably know someone who was impacted. I certainly do.

Companies increasingly believe they don’t need more engineers — they just need more LLM tokens. And tokens are much cheaper than salaries.

At the same time, universities are producing more AI graduates than ever before. Enrolment into AI-centric courses is rising rapidly, while other fields see declining interest.

The result is a strange market dynamic: a growing supply of technical talent competing for roles that are simultaneously evolving and shrinking.

There is another interesting side effect.

Generative AI has been so successful as a narrative that it has buoyed the stock market. Companies announcing “AI initiatives” can attract significant investor capital almost instantly

This trend has become so visible that the Monetary Authority of Singapore recently warned that AI and technology companies may be trading at inflated valuations. Some analysts are beginning to whisper about a potential AI bubble, reminiscent of the dot-com era.

Oh — you’re still here?

If you’re waiting for the positive spin on the above, I’m unfortunately unable to provide it.

However, I can share how I’ve personally adapted.

I graduated with a master’s degree in AI in 2023 — right in the middle of the generative AI renaissance. Fortunately, I’m still in a role where I build and ship real systems for a living.

So instead of offering optimism, I’ll offer something hopefully more useful: practical adaptation.

Here’s the first one.

1. Update your personal skills.md diligently

Since the rise of agent-driven development, many GitHub repositories have started filling up with markdown files like these:

.gemini/
.claude/
agents.md
skills.md
.cursor/rules

These files provide context that tells different agents how to behave in different environments when contributing to a repository.

And increasingly, something surprising is happening.

Many of these markdown files are now written by agents themselves.

As agents become capable of writing anything from Python, C++ to Terraform, the burden on humans has shifted.

We are no longer just writing code.

We are auditing it.

The ability to review and challenge agent-generated code is becoming one of the most important skills for modern engineers and data scientists.

Ironically, this means the solution is not to blindly chain more generative AI systems together.

For example:

You might use Claude Code to generate code and open a pull request (PR).

Another AI system, say CodeRabbit reviews the PR, rejects it, and opens a Jira ticket.

That Jira ticket then triggers Claude Code to generate a new patch.

Congratulations — you’ve now built a workflow where two autonomous agent systems argue with each other across GitHub and Jira while quietly burning LLM tokens. And you are paying for the privilege.

A better approach is: If you expect an agent to write Terraform code, then learn Terraform yourself.

Your goal is not to replace your knowledge with AI. Your goal is to raise the quality bar for the AI.

When an agent produces mediocre code, you should be able to tell it:

“This design is wrong.”

Or better yet:

“Here’s how to make it sharper.”

Your personal skills.md should evolve alongside the agents you use.

Important: focus on skills, not certifications. Certifications of today might be irrelevant tomorrow.

I’ve personally picked up — and written about — tools like Liquibase (article), Nginx (article) and Helm (article), and I’m currently learning Terraform.

Terraform is especially important to audit. Infrastructure mistakes are expensive — a single incorrect change can inflate your cloud bill while your agents happily burn LLM tokens.

I’ve also never accepted agent contributions to my code without auditing them myself.

In the age of AI-assisted development, the most valuable engineers are not the ones who rely on agents blindly.

They are the ones who can challenge them.

Besides, can you imagine how bad it looks when you’re questioned on your code contributions and all you can manage is “um…the AI did it”?

Not to mention, a wide, sharpened, evolving set of technical skills is the best career insurance.

2. Sharpen systems thinking

Many users approach AI coding agents with two implicit expectations:

• AI will handle everything required to build my application.
• AI will get everything right on the first attempt.

Both expectations are unrealistic.

Because AI can appear capable of doing everything, some people simply paste their product requirements into a prompt, ask the model to build the entire application, and walk away.

They return later only to discover that the AI built the wrong thing entirely.

The problem is not just capability — it is context.

Large language models (LLMs) operate within a finite context window. As more information is added, research shows that model performance tends to degrade. Important instructions compete with less relevant information, and the model may focus on the wrong parts of the prompt.

In other words, the model may technically have the information it needs — but still make the wrong decision. So don’t just throw your entire requirements document at it.

A better approach is to break the application into smaller, well-defined tasks, and feed them to the agent system step by step.

But that raises an important question.

How do you decide what those tasks should be?

The answer is systems thinking.

Instead of asking an AI to build an entire application at once, design the architecture first. Define the components, the responsibilities of each piece, and how they interact.

Then build the system feature by feature.

AI can write code remarkably well.

But humans still need to design the system.

For example, imagine you are asked to design a generative-AI-driven investment system for quantitative traders.

The requirements sound simple:

• The system must ingest new market information in real time.
• It must generate portfolio recommendations based on existing holdings.
• And it must respond within three seconds.

Go.

Before you even start drawing the architecture, a few uncomfortable questions appear.

Market updates arrive every second. If the agent takes three seconds to respond, the recommendation may already be outdated by the time it is generated.

The system also needs to run continuously for every ticker, which means the computational requirements — and LLM costs — could explode very quickly.

So perhaps running a full analysis on real-time data isn’t the right approach. But we may still want to ingest that data for later analysis.

Another question appears.

Are you really expecting the LLM to analyze the raw market data by itself?

Almost certainly not.

In practice, you would give the model tools to perform the heavy lifting. If those tools can already generate buy or sell signals, then the obvious question becomes:

Why do we need the LLM in the critical path at all?

A more realistic design might look like this:

Run batch analysis on historical data — daily, weekly, or monthly — to determine trading ranges.

For example:

• If price > $X → sell

• If price < $Y → buy

Now when real-time prices arrive, the system only needs to evaluate a simple boundary condition.

That decision can easily be made in under three seconds.

And suddenly the architecture becomes dramatically simpler.

You can offload the coding to the agent, but certainly not the thinking.

3. Ship code

Coding is like a muscle — stop using it and it atrophies.

Rely too heavily on code agents and it’s like paying someone else to go to the gym for you, while still expecting Thor-level biceps in your own arms.

It doesn’t work that way.

At the same time, it would also be strange to ignore copilots entirely. They are genuinely useful tools. So strike a balance.

At work, if time allows, write the code yourself first and let the copilot sharpen or optimize it.

At home, build personal projects for fun and learning — and for those projects, insist on writing most of the code yourself. I spend time on personal projects regularly and find it one of the best ways to keep up with the rapidly evolving generative AI landscape.

These projects don’t have to be large. Sometimes it’s just 30 minutes every few days working on something small, but meaningful to you.

As long as you learn something, it’s time well spent.

Because the fastest way to lose your engineering intuition is to stop building things.

4. Always be ready to explain ideas

Despite everything AI can do, the hype is still far ahead of reality.

AI tools are now widely accessible, which means your colleagues from non-technical backgrounds are experimenting with agents too. That’s not a bad thing — but it does change the role of the data scientist.

Increasingly, we become the people who need to explain things:

• Why your friend’s agent failed.
• Why a system needs more development time instead of being “copiloted into existence” .

In other words, stakeholder management is becoming a core skill for data scientists.

To do that well, you need to genuinely understand how these systems work — how agents differ, where they fail, and what their real limitations are.

You’ll also find yourself pulled into more conversations about technology stacks and infrastructure.

For example, someone might say:

“Let’s self-host Phoenix — it’s open source, so it’s free, right?”

Not exactly.

Open source software still requires infrastructure, compute, storage, and operational overhead. Someone needs to explain that, size that and design that.

How are you supposed to know all of this you ask?

I chat with LLM applications like ChatGPT/Gemini/Claude frequently about these matters. It usually starts as a general wondering (“why does every genAI framework have first class integrations only with Postgres and not any other DB?”) that gets more interesting as the chat evolves — and I end up learning something new each time.

As AI tools multiply, these conversations will only become more common.

Consider just a few examples of developer copilots:

• GitHub Copilot

• Cursor

• Claude Code

• OpenAI Codex

• Gemini CLI

Do you know how they differ?

Because sooner or later, someone will ask you.

5. Learn TypeScript

Yeah you read that right.

Python still dominates the model layer: training, experimentation, and fine-tuning. But in practice, most teams rarely fine-tune models anymore — unless you’re in a research team. It is often easier to prompt the LLM differently.

TypeScript, however, is fantastic for building things that humans actually interact with (the applications and now even the agents) in real time.

The irony is profound.

The frontend language — JavaScript’s stricter cousin — the one data scientists once believed they didn’t need, is quietly becoming the lingua franca of the agent tooling layer.

Look around the modern AI developer ecosystem:

• Claude Code — Python, AND TypeScript
• Gemini CLI — TypeScript
• OpenCode — TypeScript
• OpenClaw (and all other lobster claw descendants)— TypeScript

• Many popular model context protocols (MCPs) are heavily TypeScript. For example Postman’s MCP, Google Chrome DevTools MCP, Playwright’s MCP, etc.

And something interesting happened.

Nobody formally announced this shift. It just… happened.

One day you looked up and realized the coolest AI tools were installed with:

npm install

Not:

pip install

Frameworks like LangChain even have a JavaScript SDK that keeps pace with their Python versions.

But here’s the surprising part.

Many of the newest agentic coding tools — Claude Code, OpenCode, OpenClaw— aren’t even built on frameworks like LangChain. They talk directly to model APIs using SDKs from companies like Anthropic and OpenAI.

TypeScript itself is simply a type-safe version of JavaScript — the language that powers nearly every website on the internet.

Because of that, it has an enormous advantage: developers can use a single language across the entire stack: frontend, backend, APIs, and increasingly, AI tooling.

It may not match the raw speed of compiled languages like Java or Rust, but its dominance comes from something simpler:

One language to build everything.

The future data scientist looks a lot more like a software engineer than many of us expected.

I didn’t expect to say this as a data scientist, but TypeScript is currently at the top of my learning list — which incidentally closes the loop on the first point I made: picking up new skills.

Concluding Thoughts

Beyond the practical tips I’ve shared, perhaps the more important question is this: why did you become a data scientist in the first place?

In a previous article about my personal journey, I wrote:

The most compelling thing about artificial intelligence isn’t the hype or the job title. It’s the beauty of modeling data to create something that resembles actual intelligence — through the lens of mathematics, expressed in code.

That still rings true today, although perhaps the context has shifted slightly.

Generative AI applications are incredibly fun to build, and they carry the potential to meaningfully improve our quality of life.

Imagine an AI agent handling travel bookings, acting as your personal tour guide overseas, or helping optimize your financial portfolio, personalizing your children’s education curriculum to optimize their learning (not their grades). What if your AI agent serves as your confidante to scream at when days are hard?

What would you do with the time freed up from worrying?

Personally, I’d spend more time with my children — nurturing their curiosity for learning, guiding them in the Christian faith, and helping them grow into people who carry genuine empathy and concern for their fellow human beings.

What I won’t do is ask AI agents to do my work or my thinking for me.

AI can help us build remarkable things. But curiosity is still human.

All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.