Pallavi Ahuja recently shared something that caught my attention: "There are 2 career paths in AI right now: The API Caller... The Architect... Choose your path." It is a simple framing, but it lands because it names a real split in today’s AI job market.

In her post, Pallavi draws a sharp line: one path is learning to use AI tools through APIs, and the other is learning to build the systems behind those tools. I want to expand on what she is pointing to, add context for how these roles show up in real teams, and offer a practical way to move from "caller" to "architect" without getting lost in hype.

"The API Caller: Knows how to use an API. (Low leverage, first to be automated, $150k salary)."

"The Architect: Knows how to build the API. (High leverage, builds the tools, $500k+ salary)."

What Pallavi really means by "API Caller" vs "Architect"

Pallavi is not saying APIs are bad. In fact, knowing how to ship with APIs is useful and often the fastest way to deliver value. The point is about leverage.

An "API Caller" is someone whose core skill is wiring together existing services: prompting, calling hosted models, integrating vendor SDKs, building quick demos, and packaging it all into an app. That can be real engineering, but the dependency is high: the hardest problems (training, scaling, inference optimization, safety) are abstracted away behind someone else’s interface.

An "Architect" is someone who can go deeper: they understand model internals, data pipelines, training loops, distributed systems constraints, and inference performance tradeoffs. They can build the platform, not just the product on top of the platform.

This is why the leverage differs. When you can build the tool, you are closer to the bottlenecks that matter:

Data quality and dataset design
Model architecture choices and training stability
Throughput, latency, and cost in production
Reliability, monitoring, and regression testing
Alignment, safety, and evaluation

Why "API Caller" work is the first to be automated

Pallavi calls out a hard truth: workflows that are mostly "call this model, add a prompt, parse the output" are easier to copy and easier to automate. Vendors are racing to bundle these patterns into managed features: agents, tool calling, retrieval, eval dashboards, guardrails, even full end-to-end assistants.

If your value is mainly in glue code and prompt tweaking, you are competing with:

Rapid platform improvements that commoditize yesterday’s best practice
Internal templates and golden paths at companies
Code generation that writes the integration for you

That does not mean you should never do it. It means you should treat it as a step, not a destination.

The "Architect" advantage: you own the constraints

Architect-level work is about owning constraints end-to-end. For example:

You cannot just say "latency is high." You can profile the bottleneck and fix it.
You cannot just say "the model is wrong sometimes." You can design evaluations, curate data, and iteratively improve.
You cannot just say "it is expensive." You can quantize, batch, parallelize, cache, or redesign serving.

In practice, architect skills sit at the intersection of ML, systems, and product. This is also why compensation can diverge: the more you can directly influence cost, performance, and capability, the more irreplaceable you become.

Pallavi’s recommended resource: Stanford CS336

One reason Pallavi’s post resonated is that she did not just critique bootcamps. She pointed people to a concrete alternative: "This free 17-video Stanford course trains you to be an Architect. It’s CS336: Language Modeling from Scratch."

She also highlighted why the syllabus is "pure signal, no noise" by naming the real layers of the stack:

Data Collection and Curation (Lectures 13-14)
Building Transformers and MoE (Lectures 3-4)
Making it fast (Lectures 5-8: GPUs, kernels, parallelism)
Making it work (Lecture 10: inference)
Making it smart (Lectures 15-17: alignment and RL)

That list is almost a map of the modern LLM engineer’s job.

A practical roadmap to move from caller to architect

If you are currently shipping with APIs (which is a great place to start), here is a way to build architect capability without waiting for a perfect "study plan."

1) Keep shipping, but instrument everything

Keep building products, but add measurement:

Track latency, token usage, and cost per request
Build failure taxonomies (hallucination, refusal, tool error, retrieval miss)
Create a small evaluation set that reflects your real use cases

Architects do not guess. They measure.

2) Rebuild one layer that you currently outsource

Pick one layer below and implement a minimal version yourself:

Tokenizer and data preprocessing pipeline
A small transformer in PyTorch (forward pass, loss, training loop)
A basic inference server with batching
A retrieval pipeline you can evaluate and iterate on

You do not need to train a frontier model to learn frontier-relevant skills. You need to understand the moving parts.

3) Learn the performance story (because it becomes the product)

Pallavi’s callout on "GPUs, kernels, parallelism" is the difference between a demo and a production system. Even a simple mental model helps:

GPU utilization: are you compute-bound or memory-bound?
Batching: how do you trade latency for throughput?
Parallelism: data, tensor, pipeline parallel tradeoffs
Memory: KV cache growth and context length costs

If you can explain why your service is slow, you are already separating from most "API-only" builders.

4) Treat alignment and RL as product quality work

The "making it smart" section matters because real deployments are not just about intelligence. They are about behavior:

What should the model refuse?
How do you prevent prompt injection?
How do you evaluate helpfulness vs safety?

Even if you never run RLHF yourself, understanding the concepts makes you better at designing constraints, prompts, tools, and feedback loops.

Where bootcamps help (and where they stop)

Pallavi’s line "Bootcamps train you to be an API Caller" is not an insult. Many bootcamps optimize for quick wins: build a chatbot, connect a vector DB, deploy a web app. That is valuable early in a career.

The problem is when the curriculum ends there. If your learning never touches data curation, training dynamics, inference optimization, and evaluation rigor, you cap your leverage.

So a healthier interpretation is:

Use bootcamp-style projects to learn shipping.
Use architect-style coursework to learn foundations and systems.

You need both, but in the right order and with the right intent.

Why Pallavi’s post went viral (and what to copy ethically)

This also works as a great example of LinkedIn content that spreads for the right reasons. Pallavi did three things that drive viral posts without gimmicks:

She made a binary framework that is easy to remember ("API Caller" vs "Architect").
She attached stakes (leverage, automation risk, compensation ranges as a signal).
She offered a clear next step (a free, specific Stanford course and the exact lecture topics).

If you are thinking about content strategy, this is a useful template: a crisp model, a reason to care, and a resource that reduces confusion.

Choose your path, but choose it consciously

Pallavi ends with "Choose your path." I like that phrasing because it implies agency. Many people drift into the API-only lane because it is accessible and rewarded quickly. There is nothing wrong with that. The risk is staying there by default.

If you want longer-term leverage, start adding "architect" reps now: rebuild one layer, measure everything, learn performance, and get serious about data and evaluation. Over time, you stop being someone who only calls intelligence and become someone who can create it.

This blog post expands on a viral LinkedIn post by Pallavi Ahuja, AI | Software Engineering | Writes @techNmak. View the original LinkedIn post →