DEV Community: shayesta

My insights on What Working at Big Tech Is Actually Like

shayesta — Sat, 18 Jul 2026 08:02:25 +0000

When I was a student, I had a picture in my head of what working at a big tech company would be like. It came from the places any student's picture comes from: open-source projects, side projects, and coursework. That picture turned out to be accurate about some things and completely off about others.

None of that is a knock on the job. It's just that the day-to-day of large-scale engineering is genuinely different from what smaller-scale work prepares you for, and most people don't find that out until they're in it.

So if you're a student, a new grad, or someone eyeing the jump, here's the honest picture of what it's actually like. Not the recruiting version. The real texture of the work.

Most of the design is already done

In school, almost every project starts from a blank page. Build a distributed system. Model this domain. Pick an architecture and defend it. The blank page is the whole point — you're being taught to make decisions.

At a large company, you're usually joining something that already exists, and it exists at a scale that took years and many people to build. The architecture is set. The service boundaries are drawn. The data model and deployment patterns are in place, and usually for good reasons that predate you.

So your work happens inside that structure. You still make design decisions, but they're smaller and more local — how to build your piece well, not what the whole system should look like. The big architectural questions were answered before you arrived.

This surprises a lot of new grads, and it's worth understanding early, because it reframes what "good work" means. It's less about inventing structure and more about working skillfully within it. Different muscle, and a genuinely valuable one.

Your tools will be unfamiliar, even the familiar ones

I came in comfortable with the standard open-source stack — Maven, Gradle, the usual deployment tooling. I could build, test, and ship, and I'd done it enough to feel solid.

Then I learned that a company operating at this scale tends to build its own internal versions of almost everything. Its own build system, its own deployment tooling, its own monitoring and service frameworks, shaped around problems most open-source tools were never designed for.

The interesting part is that the concepts transfer even when the tools don't. It's all still builds, pipelines, and dependency graphs underneath. But knowing the open-source version doesn't mean you can skip learning the internal one — you learn it fresh, and lean on the concepts rather than the specifics. It's a humbling first few months, and then one day the internal tools stop feeling foreign and start feeling like tools.

A tip for anyone about to go through this: the discomfort of relearning familiar-feeling things is normal and temporary. It's not a sign you were underprepared.

A lot of the job is understanding, not writing

Here's something school doesn't quite prepare you for: at scale, the systems are too large for any one person to hold in their head.

That changes the nature of the work. A big part of senior engineering turns out to be holding context — knowing why a service behaves the way it does, which team owns which piece, what was tried before and why it didn't work. Much of that knowledge isn't written down. It lives with people, and it moves through conversations.

Which means the job is more collaborative than the heads-down stereotype suggests. Not in a politics sense — just that the information you need often isn't in any document, and knowing how to find the right person and ask a good question becomes a real, everyday skill. Learning who knows what is part of learning the system.

Debugging is more like detective work

When a project is small enough to fit in your head, debugging means reading code until you find the problem.

At scale, you're usually tracing a path through components you didn't write, owned by teams you haven't met, with behavior that emerges from how the pieces interact rather than from any single piece. So debugging becomes investigative: follow the trace, check the runbook, find the person who's seen this before, form a hypothesis, test it, learn from how it fails.

It's a skill in its own right, and a satisfying one once it clicks. The mindset shift is going from "I will read my way to the answer" to "I will investigate my way to the answer." Both get you there. They just feel very different.

You'll be oriented by firehose

Onboarding at scale is a lot at once. Documentation, access, a mentor with their own deadlines, and fairly quickly, a real task.

And that task usually assumes context you don't have yet, simply because the person who wrote it has that context and can't easily see what you're missing. So a good chunk of early work is figuring out what a task even means before you can start on it.

I've come to think this is one of the most valuable things large-scale work teaches, and nobody names it: rapid orientation with incomplete information. You get dropped into something complex, with partial docs and limited time, and you learn to find your footing and produce anyway. It's uncomfortable at first and then it becomes one of the most portable skills you own.

What it adds up to

Put it all together and the shape of the work is clear.

School and side projects mostly teach you to make things from scratch. Large-scale engineering mostly asks you to understand things that already exist, well enough to change them safely and add to them well.

Those are different skills, and the second one is underrated — it's harder to show off, harder to interview for, and closer to what a lot of senior engineering actually is. You learn what operational rigor really means. You learn how systems behave when the rare failure happens every day. You learn to work through people, and to orient yourself fast in unfamiliar territory. Small-scale work mostly can't teach these, because it doesn't generate the problems that force them.

If I could send one note back to my student self, it wouldn't be a warning. It'd just be a heads-up: the picture in your head came from open source and coursework, and the real thing is different in ways that are worth knowing in advance. Not harder or easier. Just different, and genuinely interesting once you see it for what it is.

If you've made the jump from school or smaller companies to big tech, what surprised you most? Always curious how universal this is.

What Makes a Software Engineer: The Essence of the Job

shayesta — Fri, 17 Jul 2026 02:54:44 +0000

Every so often someone asks me what software engineering actually is. A kid thinking about majors, someone considering a career switch, a relative who's genuinely curious and not just being polite.

It's a harder question than it should be, because every other profession gets a clean sentence. A doctor treats patients. A lawyer interprets law. A botanist studies plants. Four or five words and you basically get it.

We don't have that sentence. "Writes code" is wrong the same way "a surgeon holds a knife" is wrong — technically true, completely missing. "Solves problems" is worse, because it describes literally everyone.

Here's where I've landed, both on what the job is and on the part nobody mentions: who it's good for, and who it quietly makes miserable.

The word we skip

The answer's been sitting in the job title. It's engineering.

A civil engineer looks at a river and a town on the other side and builds a bridge. Nobody calls that person "someone who works with steel." Steel is just what's around. The engineering is looking at the gap and deciding what should span it.

Same deal for us. Code is our material. Look at a problem, build a system that solves it, live with how you built it.

This is why beginners get confused about what to learn. They think learning React is learning engineering. It isn't. React is this decade's steel.

Why our version is strange

So if we're just engineers, why is our job harder to describe than a bridge builder's?

A civil engineer has physics and a river that's actually sitting there. A doctor has a body. A lawyer has a legal code somebody wrote down. All of them have a referent that existed before the profession did. It pushes back. It tells them when they're wrong.

We've got nothing like that. Gravity is never going to tell you your service boundaries are bad. Every system is invented, and every constraint on it is one we made up, or inherited from someone who made it up on a Tuesday in 2019.

The object of the work doesn't exist until you make it exist. Which makes it very hard to point at.

What the job actually is

Take the tools away and four things are left:

Decomposition. Someone says "we need better fraud detection," and you have to find the seams. Where does this fuzzy thing cut into pieces you can reason about?

Modeling. Deciding what things are. Is a user the same as an account? When an order is cancelled, does it still exist? These sound like philosophy-class questions. They are. And they cost years when you get them wrong.

Tradeoffs. No correct answer, just positions on a curve. Token bucket or leaky bucket isn't about which is right. It's what you're willing to give up.

Entropy. Things you wrote last quarter are wrong now. Nobody broke them. The world moved.

So if a doctor diagnoses and a lawyer interprets, an engineer decides. Constantly, with bad information, in ways that pile up.

That last part is what I couldn't see starting out. A doctor makes a bad call and one patient is harmed. You make a bad modeling decision and it shapes every feature built on top of it for five years. That's why "it works" is a low bar, and why senior people fuss over naming things. It looks like fussiness. It's blast radius management for decisions nobody's made yet.

"So... problem solving?"

Not good enough. Plumbers solve problems. Chess players solve problems. If it describes everyone, it explains nothing.

What's actually different:

The problem usually isn't handed to you. A chess player gets a board. You get "the dashboard is slow," which might mean the query is slow, the network is slow, their expectation is off, or they need a different dashboard entirely. Half the job is figuring out what the problem even is. Most bad software is an excellent solution to the wrong one.

Your solutions become other people's constraints. Decide a user and an account are the same thing, and you've built the room fifty future features have to fit inside.

So: figure out what to build, structure it to survive change, decide what to sacrifice, then make it precise enough to run. Junior work is mostly that last step. Senior work is the first three.

The skills nobody interviews for

Tenacity. Not intelligence, and not quite discipline either. Sitting with something you don't understand, past the point where it's comfortable, without knowing how long that will last.

Selective rigor. Caring about everything equally is a liability — those people can't ship, because they can't tell what matters. The skill is knowing which three details are load-bearing and being immovable about those while relaxing about the other twenty.

A relationship with complexity. Not a fight with it. Not something you'll resolve after the refactor. It's ongoing and unresolvable, and it isn't in the way of the work — it is the work.

That last one explains most of what follows.

Who this job quietly doesn't work for

None of this is about being smart enough. Everyone below could do the work. The mismatch is what they need to find it nourishing.

People who need closure. A case gets closed. A patient gets discharged. You ship, and it starts rotting into maintenance. There's no finished. There's only stopped.

People who need visible work. You spend three weeks eliminating a whole class of failure and the result is: nothing happens. The best work you'll do is an incident that never occurred, and you can't show it to anyone.

People who need to be right. You can prove a function correct. You can't prove your architecture was, ever. Six months later you'll find out if it hurt — not whether the alternative would've hurt more.

People who need clean things to stay clean. Then you meet the workaround that has to stay because a customer depends on the bug. The gap between how it should be and how it is never closes. The people who last make peace with living in the gap.

People who flee discomfort. Careful with this one, because the obvious version is wrong. "Lazy people shouldn't be engineers" is wrong — some of the best engineers I know are motivated almost entirely by not wanting to deal with things. That's where automation comes from.

The real thing is narrower: discomfort tolerance shallower than the problem is deep. They hit "it works, ship it" and stop. Not lazy about effort. Just done being uncomfortable. The tell isn't how hard someone works, it's what they do when they don't understand something. Fix the flaky test with a retry, or ask why it's flaky. Both are working. Only one is engineering.

People whose discipline depends on the discomfort being finite. The one I find most interesting, because these are often genuinely disciplined people.

Think about how most discomfort works. You study for an exam — brutal, but there's a date and then it's over. You do a hard workout — the last reps hurt, but you can count them. Humans are remarkably good at suffering when we can see the end of it. That's most of what discipline is: borrowing against a known finish line.

Software doesn't give you the finish line. You don't know if the thing you're stuck on cracks in an hour or three days, or if the approach you've spent two days on is a dead end. There's no bell. There's no "just get through this part," because there isn't a part.

So people arrive with real discipline — the kind that got them through hard degrees — and they're confused when it doesn't transfer. It's not that they can't endure. Their endurance was structured around an ending, and this doesn't have one. The muscle is the wrong muscle.

The botanist problem

The one I think about most.

A botanist learning their 500th species has an easier time than with their 5th. Taxonomy is still true. Morphology is still true. Twenty years in they're fast, because everything they've learned still applies. Same with law.

We're not like that. Some of it compounds: data structures, distributed systems, how to model a domain. But a lot is lateral — true only inside this decade's framework, this vendor's abstraction. Your 500th tool isn't easier than your 5th, because tool 500 has nothing to do with tool 5.

I felt this hard when I joined AWS. I'd spent grad school with Maven, Gradle, and the usual open-source deployment stack. I could build and ship software. I was comfortable. Then I got here and AWS runs on its own internal tooling, and almost none of that transferred. The concepts overlapped — it's all still builds and pipelines and dependency graphs — but knowing Maven cold bought me surprisingly little. I couldn't lean on any of it. I had to learn the internal versions from scratch, like I'd never built anything before.

That's the shape of it. Not that the old knowledge was useless, exactly. Just that it was a lot less load-bearing than the years I'd spent earning it would suggest.

So you put in the years and it doesn't feel easier. It feels like running to stay in place. If you came expecting the botanist's deal — foundation, accumulation, mastery — that's a broken contract nobody warned you about.

Here's what took me a while to see: it does compound. Just not where you're looking.

Learning AWS's internal tooling was slow and humbling. But it was still faster than learning Maven had been, and I didn't notice that at the time. I wasn't learning "how builds work" from nothing — I was mapping a new thing onto a shape I already had. The overlap I couldn't use directly was still doing quiet work underneath.

That's the compounding. A senior picks up a new framework in a weekend, not because they know it, but because they've internalized the shape of frameworks and the new one is mostly a rearrangement. It's real. It's just invisible, and it feels like "huh, I've seen this before," which is much quieter than being a master of something.

If your sense of yourself needs to rest on being an expert in a named thing, this field will keep dissolving the thing.

The thing underneath all of it

Closure. Visibility. Correctness. Cleanliness. Expertise. A finish line.

Same root: this job punishes people who need the work to resolve. It rewards people who can sit in an unresolved state indefinitely without it eating at them.

The botanist accumulates. The doctor discharges. The lawyer gets a verdict. You get a system that's never done, knowledge that half-expires, decisions you'll never know were right, and a mess you're expected to be at peace with.

That's a real ask. And it's not a character flaw to want the botanist's deal instead. Most professions offer it. This one doesn't.

Who it is for

The people who love this share one thing, and it isn't raw intelligence.

They find the complexity itself interesting rather than obstructive. Not that they enjoy suffering. They just don't hear "this is tangled and unclear" as an insult. They hear the job.

The mess isn't in the way of the work. The mess is the work.

Which is why it's a relationship. Like any relationship, the question was never whether the other party is difficult. It's whether you find the difficulty compelling or exhausting.

The sentence, finally

A doctor figures out what's wrong with a body. A lawyer figures out what the rules mean for your situation. A software engineer figures out what a problem actually is, decides how to build something that won't fall over when everything changes, and writes it down precisely enough for a machine to follow — knowing every choice narrows what's possible next.

We're engineers. Code is just the material. It's the last five percent, and it's only the part anyone can see.

How do you explain this job to someone outside it? Curious whether anyone's landed on something better.

LangChain4j and Spring AI: The Plumbing to make your Java Apps talk to LLMs

shayesta — Fri, 17 Jul 2026 00:58:31 +0000

If you've heard about LangChain and assumed it was a Python thing, that's fair. It mostly was.

LangChain became popular because building with an LLM turns out to involve a lot of repetitive plumbing. You need to manage conversation history, split documents into chunks, generate embeddings, search a vector store, wire up functions the model can call, and parse whatever comes back. None of that is hard, but writing it from scratch for every project gets old fast. LangChain packaged those pieces into reusable components, and the pattern caught on.

The Java ecosystem has that now too, in two flavors. LangChain4j is a Java library built around the same idea, though it was written for Java from the ground up rather than ported over. Spring AI does the same job the Spring way, with auto-configuration and dependency injection, and it hit 2.0 this June.

Both are production ready. Your existing Spring Boot service can call an LLM in about six lines, and you don't need a Python sidecar or a separate service to do it.

The six lines aren't the interesting part, though. What matters is the distance between a chat endpoint that echoes text back and something you'd actually ship: getting typed objects instead of strings, grounding answers in your own documentation, and letting a model trigger real code in your app.

That's what this post covers. We'll build up from hello-world to a service that answers questions about your internal docs and can call your APIs, one step at a time. I'll use Spring AI for the walkthrough since most of us are already in a Boot service, then show what the same thing looks like in LangChain4j so you can pick.

I'm assuming you know Java and Spring Boot, and nothing about AI. No math, no theory, just the parts you need to build something.

One idea first, because it makes everything else fall into place.

The mental model that makes this click

An LLM is a stateless function. Text in, text out. It doesn't remember your last call, can't reach the internet, and knows nothing about your systems.

Everything below is a workaround for that:

Remember the conversation? You resend the history.
Know your internal docs? You find the relevant pages and paste them in.
Check live data? You run the function it asks for and hand back the result.

The model never does anything. Your code does everything. The model produces text, and sometimes that text is a decision about what your code should do next.

That one idea demystifies most of this space. Everything from here is plumbing around a stateless function, and plumbing is something we're already good at.

If you want more background on how LLMs, RAG, and agents fit together before diving in, I wrote about that here:

shayesta

May 29

Demystifying the AI Wave: A Backend Engineer's Guide to LLMs, RAG, and Agents

#ai #learning #llm #mcp

9 min read

Step 1: Say hello

Spring AI 2.0 needs Spring Boot 4.0+ and Java 17+.

<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-starter-model-openai</artifactId>
</dependency>

spring.ai.openai.api-key=${OPENAI_API_KEY}
spring.ai.openai.chat.model=gpt-4o-mini

@RestController
class ChatController {

    private final ChatClient chatClient;

    ChatController(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @GetMapping("/chat")
    String chat(@RequestParam String message) {
        return chatClient.prompt()
            .user(message)
            .call()
            .content();
    }
}

That's a working endpoint. Spring Boot auto-configured the ChatClient.Builder the same way it gives you a JdbcTemplate, so there's nothing new to learn about the Spring part.

Step 2: Stop getting back strings

This is where most first attempts fall apart. You ask for structured data and get back a paragraph. Or JSON wrapped in markdown fences. Or JSON with a chatty preamble in front of it. So you write a parser, then a fallback parser, then a regex. It gets miserable quickly.

Ask for a type instead:

record ActionItem(String task, String owner, String dueDate) {}
record MeetingNotes(String summary, List<ActionItem> actionItems) {}

MeetingNotes notes = chatClient.prompt()
    .user("Extract the summary and action items:\n" + transcript)
    .call()
    .entity(MeetingNotes.class);

.entity() derives a JSON schema from your record, tells the model to conform, and deserializes the response. You get an object. You can pass it around, test it, persist it.

This is the highest-leverage feature in the framework. It's what turns an LLM demo into a component you can put in a real system.

One thing that surprises people: name your fields clearly. dueDate gets better results than d2, because the schema you generate becomes part of the prompt the model sees.

Step 3: Teach it about your stuff

Ask "what's our rollback procedure?" and the model will confidently invent one. The fix is unglamorous. You find the relevant docs and paste them into the prompt.

That's RAG (Retrieval-Augmented Generation). The name sounds architectural, but it's really a paste operation with a good search in front of it.

The only interesting part is the search. Keyword matching is too brittle here, because the user asks about "rollback" while your runbook says "reverting a bad deploy." So instead you use embeddings. Each chunk of text gets converted into a vector that represents its meaning, and similar meanings end up near each other. Now those two phrases match even though they share no words.

Load your docs once:

var reader = new TextReader(runbook);
var splitter = new TokenTextSplitter();
vectorStore.add(splitter.apply(reader.get()));

Wire retrieval in:

@Bean
ChatClient ragChatClient(ChatClient.Builder builder, VectorStore vectorStore) {
    return builder
        .defaultAdvisors(new QuestionAnswerAdvisor(vectorStore))
        .build();
}

Ask:

String answer = ragChatClient.prompt()
    .user("What's our deployment rollback procedure?")
    .call()
    .content();

Notice the calling code is identical to Step 1. Nothing about it says "RAG." The QuestionAnswerAdvisor sits in the middle and does the work: it intercepts the request, embeds the question, searches the store, injects the matches into the prompt, then passes it along.

That's the Advisor pattern, and it's the core idea in Spring AI. If you've ever written a servlet Filter or a HandlerInterceptor, you already know the shape. Memory, retries, and tool calling all work the same way.

Step 4: Let it do things

RAG can only surface documents you loaded ahead of time. It can't tell you whether an order shipped, because that's a live lookup rather than a document. For that you need tool calling.

The name is a little misleading, because the model does not call your tool. Here's what actually happens:

You describe your functions to the model.
The model replies: "I'd like to call getOrderStatus with orderId=A1234."
Your code runs it.
You send the result back.
The model answers using it.

The model decides, your code does. In practice Spring AI hides steps 2 through 4 from you. You just write the method:

@Component
class OrderTools {

    @Tool(description = "Look up the current status of a customer order by its ID")
    String getOrderStatus(@ToolParam(description = "The order ID, e.g. A1234") String orderId) {
        return orders.findById(orderId).map(Order::status).orElse("Not found");
    }
}

String answer = chatClient.prompt()
    .user("Has order A1234 shipped yet?")
    .tools(orderTools)
    .call()
    .content();

The description is the API. It isn't documentation for humans. It's the only thing the model uses to decide whether your method is the right one to call, so a vague description gets you wrong calls.

Worth knowing if you're reading older tutorials: Spring AI 2.0 moved the tool-calling loop out of the individual chat models and into the advisor chain. In 1.x you could call tools, but you couldn't build on top of the loop itself. Now you can intercept and compose around it, which matters a lot if you're building agents.

Where MCP fits

You'll hear a lot about MCP (Model Context Protocol) right now, and it gets conflated with tool calling constantly. The distinction is simple: tool calling is the capability, MCP is a delivery mechanism. Everything in Step 4 works without MCP.

MCP answers a different question: what if that tool should be available to other apps too? Instead of every team hardcoding their own version of the same integration, the tool lives in a standalone server that any MCP-compatible client can connect to. It's a standard interface, closer to USB than to a new kind of electricity.

If you're building one app with a handful of your own tools, skip it and use Step 4. If you want to reuse tools across services, or plug into the growing ecosystem of pre-built servers, that's when MCP earns its place.

The same thing in LangChain4j

Everything above works in LangChain4j too. The difference is philosophical: Spring AI is opinionated about composition, so everything flows through the advisor chain and Spring wires it up for you. LangChain4j hands you independent building blocks and lets you assemble them yourself.

Its best feature is AI Services. You declare an interface and it generates the implementation:

SupportAssistant assistant = AiServices.builder(SupportAssistant.class)
    .chatModel(model)
    .contentRetriever(retriever)     // RAG
    .tools(new OrderTools(orders))   // tool calling
    .chatMemory(MessageWindowChatMemory.withMaxMessages(10))
    .build();

That's all four steps in a single builder. If you've used Spring Data repositories or Feign clients, the pattern needs no explanation: you describe what you want in a typed interface, and the library handles the rest.

	Spring AI	LangChain4j
Best when	You're already on Spring Boot	Quarkus, Micronaut, or plain Java
Style	Auto-configured, opinionated	Assemble it yourself
Core idea	Advisor chain	AI Services
Observability	Micrometer built in	Bring your own

Use LangChain4j if you're not on Spring, or if you'd rather own the composition yourself. Use Spring AI if you're already in a Boot service and want auto-configuration, Micrometer observability, and the advisor chain to build on.

Both are good. This isn't a decision worth agonizing over, so pick the one that matches the stack you're already in.

Two things worth knowing

Token usage matters more than framework overhead. Network latency to the model dwarfs any abstraction cost, so don't pick a framework on performance. What does add up is tokens. Both frameworks quietly append things to your requests: memory, RAG chunks, tool definitions. Log what's actually going out before you scale.

You probably want RAG, not fine-tuning. Use RAG when the model needs to know something, like your docs or current data. Use fine-tuning when it needs to behave a certain way, like matching a tone or format. Most people reaching for fine-tuning actually want RAG, which is cheaper and updates by writing to a database.

Start smaller than feels worthwhile

Get a ChatClient returning a string. That's an afternoon. Then make it return a record instead, which is the moment it stops being a toy. Then add one tool. Then add RAG.

Each step is genuinely small, and the libraries are good enough now that the plumbing mostly disappears. What's left is the interesting part: deciding what your system should actually do.

Spring AI reference — start with ChatClient and Advisors
LangChain4j docs

⚠️ Heads-up: Spring AI 2.0 was a real redesign with breaking changes from 1.x, and a lot of tutorials you'll find online are still written against 1.x. Check which version you're reading before you copy anything.

Syntax is boring: A mental model to learning a new programming language fast!

shayesta — Mon, 01 Jun 2026 11:33:29 +0000

When learning a new programming language, the default approach is usually to start with the syntax. For complete beginners, starting with syntax and gradually moving toward language features makes perfect sense. However, for experienced developers, focusing on syntax first is rarely the most efficient use of time. The issue is that the time spent memorizing keywords yields very little insight into how a language actually handles logic, how it behaves under the hood, or what tools it places at a developer's disposal. Because syntax tends to look remarkably similar across related paradigms anyway, the grammar rules can easily be picked up on an as-needed basis.

A more strategic approach focuses on the language features, internal behaviors, and underlying scaffolding that give a language its distinct identity. Diving into the semantics, constructs, features, idioms, and type system features first provides the ideal roadmap to learning a language at an accelerated pace. By understanding these architectural elements before worrying about syntax, one gains a deeper technical vocabulary that completely changes how they think in that language. Ultimately, this approach empowers developers to write cleaner code, dodge common anti-patterns, and build systems in a far more efficient way.

Even in an era dominated by Generative AI, where code can be instantly generated or interpreted via simple prompts, mastering these core principles remains highly valuable. You still have to read and review code and It builds your problem-solving muscle. The goal is to absorb the core concepts first, saving syntax practice for simple, hands-on exercises later.

Since my own background is rooted in Java and its ecosystem, the examples throughout this article will naturally reference Java and Kotlin concepts. That said, this approach itself is not Java-specific; the same four pillars apply when picking up any language, and you can substitute your own familiar language wherever Java/Kotlin appear in these examples(mostly).

The Four Core Architectural Pillars

1. The Type System

Think of a type system as a set of rules that tells the compiler or runtime what kind of data something is, and what you are and are not allowed to do with it. It is the grammar of a programming language. It enforces correct usage across your variables, functions, and other constructs, catching misuse before it becomes a runtime crash.

Grasping the nuances of a type system early on is vital for navigating any programming language. If you don't understand the rules, you'll constantly fight the compiler or face strange bugs.

A simple way to think about it: if a function expects a Boolean, you cannot return an int. If a variable is declared as a List, you cannot assign a HashMap to it. The type system is what catches that. It tells you what operations are valid on a given piece of data, what can be passed where, and what the compiler can guarantee for you before the program ever runs.

This is not just about preventing errors. Type systems make code more readable, more maintainable, and more reliable, which is why they matter especially in large-scale software development where many developers are working across the same codebase.

Static, Dynamic, and Type Inference

Languages handle types in different ways and knowing which approach a language takes tells you a lot about how it behaves.

Static typing types are checked at compile time. The compiler knows the type of every variable before the program runs. Java is statically typed. If you try to assign a String to an int, the compiler refuses to build.

int age = "thirty"; // compiler error — caught before runtime

Dynamic typing types are checked at runtime, not compile time. Python is dynamically typed. The flexibility is real, but so is the risk; type errors only surface when that line of code actually executes.

age = "thirty"
age + 1  # no error until this line runs — then it crashes

Type inference the compiler figures out the type for you so you do not have to declare it explicitly. This is not dynamic typing. The type is still fixed and checked at compile time; the compiler just deduces it from the value. Kotlin uses type inference extensively.

val age = 30        // compiler infers Int — still statically typed
val name = "Alice"  // compiler infers String

Java added limited inference with var in Java 10, but Kotlin leans on it as a default. This is one of the first things worth noting when moving from Java to Kotlin; less ceremony, same safety.

Polymorphism

A strong type system also supports polymorphism, the ability for functions and methods to operate on different types without redundancy. Instead of writing the same logic multiple times for different types, you write it once and the type system handles the variation.

In Java, generics are the primary mechanism for this:

// without polymorphism - redundant
int findMax(int[] arr) { ... }
double findMax(double[] arr) { ... }

// with generics — one implementation, works for any comparable type
<T extends Comparable<T>> T findMax(T[] arr) { ... }

In Kotlin this becomes even more expressive. The type system is richer, and combined with extension functions and sealed classes, you can write highly general code that is still completely type-safe.

Why Grasping the Type System Early Matters

Understanding the type system early cuts down your learning time considerably, for a few reasons.

It tells you what the language can and cannot guarantee. A language with a strong static type system like Kotlin or Rust is giving you a very different set of promises than Python. Knowing this upfront shapes how you design functions, handle errors, and structure data.

It surfaces the common pitfalls immediately. In Java, the distinction between primitive types and reference types causes real bugs, boxing and unboxing, null references on Integer vs int. In Kotlin, nullability is part of the type system itself, so the entire class of null pointer exceptions that Java developers spend years navigating is addressed at the language design level. Knowing this on day one changes how you write code from day one.

It gives you a vocabulary for the rest of the language. Generics, variance, sealed classes, type inference. These concepts connect to each other. Once you understand how the type system works, constructs that initially look arbitrary start to make sense as deliberate design decisions.

How to Identify What a Language Offers in Terms of Type System

When you first approach a new language and you already know another one, ask these questions:

Is it statically or dynamically typed? This is the first fork in the road. It tells you whether errors surface at compile time or runtime and shapes your entire development workflow.
Does it have type inference? If so, how much? Kotlin infers almost everything. Java infers sparingly. This affects how verbose the code looks and how much the compiler is doing for you.
How does it handle null? Java allows null on any reference type and trusts you to check. Kotlin encodes nullability into the type itself; String cannot be null, String? can. Rust has no null at all. This one question tells you a lot about the language's philosophy.
Does it support generics? If so, how does it handle variance, the relationship between generic types when their type parameters are in a subtype relationship? Java uses wildcards at the call site. Kotlin uses in and out at the declaration site. The mechanism is different but the problem being solved is the same.
Does it support polymorphism through the type system? And how, through inheritance, interfaces, generics, or something else like type classes in Haskell?

Answering these questions about a new language, using your existing language as the reference point, gives you a working map of the type system in a short amount of time. That map then makes every other construct in the language easier to understand.

2. Language Constructs

A construct is a structural building block the language gives you to express a specific idea, a control flow, a data structure, or a behavior. Syntax is the punctuation. The construct is the meaning behind it.

Every language gives you a set of constructs. Learning those constructs is learning what the language is actually capable of.

Control Flow Constructs

These determine how execution moves through your program.

Java's switch is a statement, it does not return a value. Kotlin's when is an expression, it does. Same problem, different construct, different behavior.

// Java — switch statement
switch (status) {
    case "active": result = "running"; break;
    default: result = "unknown";
}

// Kotlin — when expression
val result = when (status) {
    "active" -> "running"
    else -> "unknown"
}

Other control flow constructs: if/else, for, while, try/catch/finally, break, continue, return, throw — exist in both languages with mostly similar behavior, though in Kotlin if and try are also expressions.

Type Declaration Constructs

These define the shape and nature of your types.

Java gives you class, abstract class, interface, enum, record (Java 16+), and sealed class (Java 17+). Kotlin has equivalents for all of these but with meaningful differences in each.

data class in Kotlin is a dedicated construct for holding data. One line replaces fifty lines of Java boilerplate:

// Java - a class that just holds data
public class User {
    private final String name;
    private final int age;
    public User(String name, int age) { this.name = name; this.age = age; }
    public String getName() { return name; }
    public int getAge() { return age; }
    // plus equals(), hashCode(), toString()...
}

// Kotlin - same thing
data class User(val name: String, val age: Int)

sealed class in Kotlin is more powerful than Java's version; each subtype can carry its own data, and when forces exhaustive handling:

sealed class Result {
    data class Success(val data: String) : Result()
    data class Error(val message: String) : Result()
}

val message = when (result) {
    is Result.Success -> result.data
    is Result.Error -> result.message
}

Object Model Constructs

These govern how objects are built, related, and interact.

Java and Kotlin both have constructors, instance methods, static methods, fields, extends, implements, instanceof, and casting. The differences are in the details.

In Kotlin, classes are final by default, you must explicitly use open to allow inheritance. Java is the opposite.

// Java - inheritable by default
class Animal { }
class Dog extends Animal { }

// Kotlin - final by default, must opt in
open class Animal
class Dog : Animal()

this() and super() exist in both for constructor chaining, but Kotlin introduces primary and secondary constructors as distinct constructs with their own syntax and execution order.

Access & Visibility Constructs

These control what can see and touch what.

Java has public, private, protected, and package-private (the default — no modifier). Kotlin has the same plus internal, which restricts visibility to the module; something Java has no direct equivalent for.

Type System Constructs

These define how the language thinks about data.

Both languages have primitive types, reference types, arrays, generics, varargs, and type casting. The key differences:

Kotlin has no primitive types from the developer's perspective. Everything looks like an object, and the compiler decides whether to use a JVM primitive underneath. Java forces you to think about int vs Integer explicitly.

// Java — you manage the distinction
int a = 5;          // primitive
Integer b = 5;      // reference — can be null, has overhead

// Kotlin — you just write Int, compiler handles the rest
val a: Int = 5

Type inference in Kotlin is far more pervasive than Java's var:

val name = "Alice"     // inferred as String
val numbers = listOf(1, 2, 3)  // inferred as List<Int>

Behavioral & Functional Constructs

These define how behavior is expressed and passed around.

Java requires a functional interface for lambdas to work against. Kotlin treats function types as first-class citizens in the type system.

// Java — lambda needs a functional interface
Runnable r = () -> System.out.println("Hello");

// Kotlin — function type is a direct type
val greet: () -> Unit = { println("Hello") }

fun run(action: () -> Unit) = action()
run { println("Hello") }

Method references work similarly in both but Kotlin's are more flexible given the richer type system.

Memory & Execution Constructs

These control where things live and how they behave at runtime.

static in Java becomes companion object in Kotlin, statics become actual objects with their own scope. synchronized exists in both. volatile and transient exist in Java; Kotlin exposes them as annotations (@Volatile, @Transient).

// Java
public class Config {
    public static final String VERSION = "1.0";
}

// Kotlin
class Config {
    companion object {
        const val VERSION = "1.0"
    }
}

Standard Library Constructs

Both languages treat certain standard library types as near language-level primitives. String gets special treatment in both. String templates in Kotlin make this more expressive:

// Java
String greeting = "Hello, " + name + "!";

// Kotlin
val greeting = "Hello, $name!"

Collections (List, Set, Map, Queue), Optional (Kotlin uses nullable types instead), Stream (Kotlin has collection extensions that replace most stream use), and Iterator/Iterable exist in both, with Kotlin's versions generally requiring less ceremony.

Why This Matters

The constructs a language gives you reflect what it was designed to do well. Kotlin has data class, sealed class, and extension functions because it was designed to reduce boilerplate and model problems expressively. Java's constructs reflect its object-oriented roots and its evolution over thirty years. Learn the constructs and you learn the philosophy and that is what lets you write code that actually belongs in the language.

Semantics

Syntax is the grammar i.e. where the brackets go, how you declare a variable, what keywords look like. Semantics is what the code actually does when it runs. Two languages can have similar syntax and completely different semantics, or different syntax and nearly identical semantics.

Semantics covers things like: what happens to a variable when it goes out of scope, whether a value is copied or referenced when passed to a function, what a keyword actually does to memory, and when and how exceptions propagate.

Example 1: What `static` actually means

The keyword exists in Java. The semantic question is what it does.

// Java
public class Counter {
    static int count = 0;  // belongs to the class, shared across all instances
    int id;

    public Counter() {
        count++;
        this.id = count;
    }
}

Counter a = new Counter();
Counter b = new Counter();
System.out.println(Counter.count); // 2 — shared, not per instance

static means the field belongs to the class itself, not to any instance. Every object shares it. That is the semantic. The syntax is just the keyword. Understanding the semantic tells you why modifying a static field in one place affects every object.

Kotlin does not have static. The semantic equivalent lives in a companion object:

class Counter {
    companion object {
        var count = 0
    }
    val id: Int

    init {
        count++
        id = count
    }
}

Counter()
Counter()
println(Counter.count) // 2

Same semantic, shared state belonging to the type, not the instance; different construct.

Example 2: Null semantics

In Java, any reference type can be null. The language makes no distinction at the type level between a variable that might be null and one that never will be.

String name = null;       // allowed — no type-level indication this is risky
name.length();            // NullPointerException at runtime

The semantic here is: null can appear anywhere on a reference type, and the language will not stop you. The error surfaces at runtime.

In Kotlin, nullability is part of the type itself.

val name: String = null   // compile error — String cannot be null
val name: String? = null  // allowed — the type explicitly permits null
name.length               // compile error — must handle null first
name?.length              // safe call — returns null if name is null

The syntax is different but the more important thing is the semantic: Kotlin moves the null decision from runtime to compile time. This changes how you design functions and how you think about data flow.

Example 3: Pass by value vs pass by reference

Java passes everything by value. For primitives that means the value itself is copied. For objects it means the reference is copied; not the object.

void modify(List<String> list) {
    list.add("new item");  // modifies the original — reference was passed by value
}

void reassign(List<String> list) {
    list = new ArrayList<>();  // does nothing to the original — local copy of reference
}

Understanding this semantic prevents a specific category of bugs. The syntax tells you nothing about it. You have to know what the language actually does when you pass an argument.

Kotlin has the same semantics here because it runs on the JVM, but it adds val and var to make mutability intent explicit:

fun modify(list: MutableList<String>) {
    list.add("new item")  // modifies original
}

The type MutableList vs List is now part of the semantic contract, whether something can be modified is visible at the call site.

Why Semantics Matter When Learning a New Language

Semantics tells you how the language behaves; not how it looks. Two languages can share similar syntax and behave completely differently under the hood. If you only learn the syntax, you will write code that compiles but does not do what you expect.
When you understand the semantics of a language early, you stop being surprised by it. You know why a static field behaves differently from an instance field. You know why passing an object to a function can modify the original. You know why a null reference crashes at runtime in Java but is caught at compile time in Kotlin. These are not syntax questions. They are behavioral questions, and getting them wrong costs debugging time.
Learning the semantics of a new language through the lens of a language you already know is one of the fastest ways to build an accurate mental model. You are not starting from zero, you are mapping known behavior to new behavior, and noting where the two diverge. Those divergence points are where bugs come from, and knowing them upfront is a significant advantage.

Idiomatic Usage

Idioms are the patterns an experienced developer in that language reaches for by default. Not the only way to do something, but rather, the preferred way. Code that is non-idiomatic works but signals to anyone reading it that the author is new to the language.

The most useful exercise when learning idioms in a new language is to take something you would do naturally in your familiar language and ask: how does this community solve the same problem?

Example 1: Building a string with conditions

Non-idiomatic Java written by someone who learned C first:

String result = "";
for (int i = 0; i < items.size(); i++) {
    result = result + items.get(i);  // string concatenation in a loop
}

Idiomatic Java:

String result = String.join(", ", items);
// or with streams
String result = items.stream().collect(Collectors.joining(", "));

Same output. The idiomatic version uses the tools the language provides rather than reimplementing them manually.

Example 2: Transforming a list

Non-idiomatic Java written by someone thinking in C++:

List<String> names = new ArrayList<>();
for (User user : users) {
    names.add(user.getName());
}

Idiomatic Java:

List<String> names = users.stream()
    .map(User::getName)
    .collect(Collectors.toList());

Idiomatic Kotlin:

val names = users.map { it.name }

All three produce the same result. The Kotlin version is the shortest not because of syntax alone but because Kotlin's collection extensions and lambda idioms are designed for exactly this pattern. Writing the loop version in Kotlin works but reads as someone bringing Java habits into Kotlin.

Example 3: Null handling

Non-idiomatic Kotlin written by someone coming from Java:

if (user != null) {
    if (user.address != null) {
        println(user.address.city)
    }
}

Idiomatic Kotlin:

println(user?.address?.city)

The safe call operator is not just shorter. It is the construct Kotlin provides specifically for this pattern. Using nested null checks in Kotlin signals unfamiliarity with the language.

Example 4: Scope functions

Kotlin's scope functions: let, apply, run, also, with have no direct Java equivalent. They are idiomatic Kotlin for operating on an object within a contained scope.

Non-idiomatic Kotlin (Java thinking):

val user = User()
user.name = "Alice"
user.age = 30
user.email = "alice@example.com"
saveUser(user)

Idiomatic Kotlin:

val user = User().apply {
    name = "Alice"
    age = 30
    email = "alice@example.com"
}
saveUser(user)

apply runs a block on the object and returns the object itself. It is the idiomatic way to configure an object during construction. Using it signals that you understand how Kotlin expects you to work with object initialization.

Why Idioms Matter When Learning a New Language

Every language has a community of developers who have been using it for years and have converged on preferred ways of solving common problems. Those preferences are the idioms. They exist because the language was designed with certain constructs in mind, and the idiomatic patterns are the ones that use those constructs the way they were intended.
Learning idioms early does two things. First, it makes your code readable to other developers in that language. Non-idiomatic code works but it signals immediately that you are new. Second, and more practically, idiomatic code is usually shorter, less error-prone, and better aligned with how the language's standard library and tooling are designed to work.
The fastest way to pick up idioms is to find real codebases written by experienced developers in that language and read them. Notice the patterns that repeat. Notice what they reach for when transforming a list, handling a null, initializing an object, or managing a resource. Then ask: what is the equivalent of this in the language I already know, and why did this community choose a different approach? That question alone will teach you more about a language than any syntax guide.

The Actual Point

The four things — constructs, type system, semantics, idioms, are not a curriculum. They are a lens. When you pick up a new language, you are not sitting down and studying each one exhaustively before moving on. You are using them as a way to ask smarter questions faster.

The developer who learns a new language by reading the syntax guide is asking: how do I write this? The developer who uses these four lenses is asking: what does this language give me, how does it behave, and what does it expect of me? That second set of questions gets you productive faster because you are building a mental model, not memorizing notation.

The Real Benefit - Pattern Recognition

If you already know one language well, you already understand constructs, type systems, semantics, and idioms, you just know them in that language. What you are actually doing when learning a new language is looking for the equivalent of what you already know, and noting what is missing, what is different, and what is genuinely new.

That process is fast. A developer who knows Java can look at Kotlin for a few hours and immediately map most of it. Classes exist. Interfaces exist. Generics exist. Null handling works differently. Static does not exist, companion object does. Data class is new. Sealed class is more powerful than Java's version. Scope functions have no equivalent.

That mapping, done through the lens of constructs, type system, semantics, and idioms, gives you an accurate picture of the language in a fraction of the time it would take to read through documentation linearly.

Looking for the Presence of These Things

When you first open a new language, the useful questions are:

Does this language have a static type system or a dynamic one? That one answer tells you a lot about how the language will behave and what kind of errors you will catch early versus late.

What constructs does this language have that mine does not? Those are the things worth spending real time on. Everything that maps directly to what you already know you can skim.

Where does this language's behavior diverge from what I expect? Those divergence points are the semantics worth studying. They are where the bugs will come from.

What does production code in this language actually look like? Reading real code written by experienced developers surfaces the idioms faster than any documentation.

You do not need to study all four exhaustively. You need to be aware enough of them to know what questions to ask and where to focus your attention.

Why It Is Faster Than Syntax-First

Syntax-first learning gives you the ability to write code that compiles. That is its ceiling. You can declare variables, write loops, define classes. But you have no feel for the language. You do not know what it is good at, what patterns it encourages, or what assumptions it makes about how you will use it.

Learning through constructs, type system, semantics, and idioms gives you a working mental model first. Once you have that, the syntax fills itself in naturally as you write code. You are not memorizing notation; you are expressing ideas you already understand in a new notation. That is a fundamentally faster process.

The developer who learns syntax first spends weeks writing code that works but does not fit the language. The developer who builds the mental model first writes code that fits from the start, and picks up the syntax in days just by writing.

The Paradigm Caveat: When the Worldview Changes

When moving between languages in the same paradigm, the transition is smooth. However, crossing a major paradigm boundary fundamentally changes the game:

Java → Haskell (Imperative → Pure Functional)
Python → Prolog (Imperative → Logic)
C → Erlang (Sequential → Actor Model / Concurrent)

In these cases, the constructs themselves feel alien because they rest on an entirely different computational worldview. Attempting to learn Haskell's typeclasses before understanding pure functions is like studying the luxury features of a car before understanding that engines exist. When the paradigm distance is wide, the learning order must flip: paradigm first, constructs second, syntax last.

Internalizing a Paradigm Shift

Mastering a new paradigm requires absorbing the core rules that govern how the language approaches problems:

The Functional Worldview — functions are treated as first-class values that can be stored and passed. Immutability is the default state, shared state is eliminated, and computation is viewed as a series of data transformations rather than state mutations.

The Logic Worldview — programming becomes a matter of describing what is true, rather than writing step-by-step execution instructions. The runtime engine handles computation via search.

The Actor Worldview — concurrency is treated as the foundational mental model rather than an optimization detail. Isolated processes share absolutely no state, communicating entirely through asynchronous messages where system failure is expected and explicitly designed for.

Choosing a Learning Order Based on the Situation

Relationship	Optimal Learning Order
Same paradigm, different language (e.g., Java → Kotlin)	Constructs → Standard library → Syntax
Adjacent paradigm (e.g., Java → Scala)	Core paradigm shifts → Constructs → Syntax
Different paradigm (e.g., Java → Haskell)	Paradigm → Mental model → Constructs → Syntax
First language ever	Syntax → Basic constructs → Paradigm gradually

Demystifying the AI Wave: A Backend Engineer's Guide to LLMs, RAG, and Agents

shayesta — Fri, 29 May 2026 12:25:07 +0000

Table of Contents 🗒️

Where it all starts: LLMs
Making LLMs smarter: RAG
Plugging everything in: MCP
The big leap: AI Agents
A tale of two protocols: MCP and A2A
Where does this leave us as engineers?
LangChain: The Backbone of AI Engineering

I've been diving deep into AI lately, trying to demystify this massive wave that's been taking the industry by storm. For a bit of background: I'm a backend software engineer and my sweet spot is Java. I absolutely love solving complex system design problems using object-oriented programming.

I first dipped my toes into AI back in early 2023 when ChatGPT went viral. Back then, I used it like everyone else; as a handy chatbot for quick answers. But recently, I realized it's time to move past just using AI and start actually building with it. So I did what any curious engineer would do: I went down the rabbit hole. Countless blog posts, YouTube videos, and Google's free AI Agents intensive course later, I finally feel like things are starting to click.

Now that the dust has settled, I've built a solid mental model of how AI, LLMs, and agents fit together. In this post, I want to share that roadmap and give you a clear, high-level overview of the core concepts you need to know to start building too. Think of this as your cheat sheet; a quick ramp-up for software engineers that cuts through the noise and gives you direction without the overwhelm.

Where it all starts: LLMs 🤖

Our first real introduction to modern AI was through Large Language Models, or LLMs. On the surface it seems simple: you type a question, and the LLM spits out an answer. Under the hood though, it pulls off this magic using two core pillars: Transformers and Vector Databases.

When you first start looking into AI, it's really easy to feel overwhelmed. You might think you need to familiarize yourself with traditional machine learning concepts like

Supervised and unsupervised learning
K-Means clustering
Q-learning
Principal Component Analysis (PCA)
Logistic regression and many more...

But let me cut down the noise for you: as a software engineer, you don’t need to know all of that just yet. While you can certainly learn those traditional ML algorithms later if you're curious, they aren't prerequisites for building with generative AI today.

1. Vector Embeddings: The AI's Language 💬

Computers don't get words, but they love math. Vector embeddings are the ultimate translator. They take human text and convert it into a massive string of numbers (a vector).

The trick here is that these numbers represent meaning. Think of it like a giant, multi-dimensional map. Words that mean similar things get placed right next to each other on the map.

In practice: "King" and "Queen" will have coordinates right next to each other, while "Apple" will be parked miles away.

2. Transformers: The Brain 🧠

If embeddings are the vocabulary, the Transformer is the brain doing the reading. It’s the game-changing neural network architecture behind every major LLM today.

Old-school AI used to read sentences sequentially—one word at a time—which meant it totally lost the plot by the end of a long paragraph. Transformers process the entire text block all at once. Using something called the Self-Attention Mechanism, the model instantly links words together to figure out context, no matter how far apart they are in the sentence.

In practice: If you say, "The bank of the river was muddy, so I couldn't withdraw cash," the Transformer instantly hooks the word "bank" to "river" and "withdraw" at the exact same time, perfectly sorting out the double meaning.

3. Vector Databases: The Filing Cabinet 🗄️

Standard SQL databases are great for exact matches, but they are completely blind to nuance. If you search a SQL database for "refund policy," it won't find a document that says "cashback guidelines" because the characters don't match.

A Vector Database (like pgvector or Pinecone) is a specialized filing cabinet built to store and search those numeric coordinates we talked about. Instead of looking for exact letters, it calculates geometric distance. It takes your prompt, turns it into a coordinate, and pulls the files that are physically closest to it in semantic meaning.

The TL;DR Pipeline:

When you hit enter on a prompt, they all high-five:

Your text becomes a Vector Embedding (coordinates).
The Vector Database finds the closest matching data coordinates.
The Transformer eats your prompt + that data all at once, handles the context, and spits out the perfect answer.

If you want a fantastic visual breakdown of how transformers work under the hood, I highly recommend this video and some of the ones linked below:

Making LLMs smarter: RAG

Now that we've pulled back the curtain on Transformers and vector databases, let's talk about the next logical step: RAG, or Retrieval-Augmented Generation.

Out of the box, foundational LLMs, namely, Google Gemini, OpenAI GPT-4o, Anthropic Claude, or Meta Llama 3, only know what they were trained on. Ask them about anything outside that, like recent news or your company's internal documents, and they'll either admit they don't know or worse just hallucinate something.

RAG solves this. Instead of forcing the LLM to rely purely on its memory, RAG lets the model pull in real-time information from external sources before it responds. It's the difference between a colleague who only remembers what they studied in school versus one who can actually Google things before answering you.

Plugging everything in: MCP

So RAG lets LLMs reach out for external data, but how does a model connect to all these different sources without developers writing custom integrations every single time? That's where MCP, the Model Context Protocol, comes in.

Introduced by Anthropic as an open-source standard, MCP is basically the USB-C port of AI. Just like HTTP standardized how browsers talk to servers, MCP standardizes how AI models and agents securely fetch data from tools, databases, and file systems. It works through a simple client-server setup:

MCP Clients

The AI apps or agents (think Claude Desktop, Cursor, or ChatGPT) that need external context or want to trigger an action.

MCP Servers

Lightweight programs that connect to specific data sources (like GitHub, Google Drive, or a Slack workspace) and expose that data to the client.

Put RAG and MCP together, and you've gone from a chatbot that only knows what it was trained on to a connected assistant that can work with real-world, real-time data. Pretty powerful upgrade!

The big leap: AI Agents

This is where things get really exciting. To understand why agents are taking the industry by storm, you first need to understand what actually separates an agent from a plain LLM:

An LLM is the brain. It's a powerful model trained on massive amounts of data, but it's fundamentally reactive. You give it a prompt, it processes it, it gives you a response. That's it. No planning, no follow-through.
An AI Agent is the worker. An agent wraps that same LLM in a loop of planning, memory, and tools. It's proactive and goal-oriented. You hand it a complex objective and it figures out how to get there on its own.

A fully realized AI Agent pulls together four things to make that happen:

The Brain (LLM) — The core engine for reasoning and understanding language.
Planning & Reflection — Using patterns like ReAct (Reason + Act), the agent doesn't just answer immediately. It thinks out loud: "To accomplish this, I need to check X first, then evaluate Y, and if that fails, try Z."
Memory — Short-term memory to track what it's already done in the current session, and long-term memory via vector databases to remember preferences or past interactions across sessions.
Tools — This is where MCP or traditional APIs come in. Tools give the agent hands. It can write code, query a database, read a file, send an email — whatever it takes to execute the plan.

We ended up with agents because LLMs, as brilliant as they are, are kind of helpless on their own. Give them memory and a toolkit, and suddenly they can coordinate and knock out complex, multi-step tasks that no single LLM could accomplish on its own.

A Tale of Two Protocols: MCP and A2A

1. MCP: The Vertical Layer (Agent-to-Tool)

As we covered, Anthropic’s Model Context Protocol (MCP) handles how a single agent talks down to its environment. It connects the model vertically to your infrastructure, giving it read/write access to internal SQL databases, filesystem resources, or internal company APIs. MCP is about giving an isolated brain a set of hands to touch data.

2. A2A: The Horizontal Layer (Agent-to-Agent)

Originally introduced by Google, the Agent-to-Agent (A2A) Protocol handles how agents talk horizontally to each other. In complex enterprise systems, you don't build one massive, monolithic agent that knows how to do everything. Instead, you build a network of micro-agents: a coding agent, a billing agent, and a DevOps agent.

A2A defines how these independent nodes discover each other across a network using cryptographic "Agent Cards" (JSON manifests that advertise an agent's specific skills and authentication requirements). Using A2A, a primary agent can securely negotiate, delegate sub-tasks, and stream status updates to another agent across organizational boundaries—even if one is built on LangChain and the other is built on an entirely different framework like CrewAI etc.

The Architectural Takeaway

They aren't competitors; they are a complementary stack. Think of MCP as the internal bus inside a computer linking the CPU to the hard drive, and A2A as the internet protocol (like HTTP) allowing completely separate computers to collaborate.

As a backend engineer, this architecture should feel incredibly familiar. We are essentially watching the wild west of AI reshape itself into a standard, decoupled microservices architecture.

Where does this leave us as engineers?

This is exactly where the industry is heading. Our role as software engineers is shifting from writing rigid, deterministic code to building these dynamic agentic workflows. And the good news? You don't have to build everything from scratch.

The complex coordination loops, retry logic, and state management have already been abstracted away by solid frameworks and the most important one to know about is LangChain.

LangChain: The Backbone of AI Engineering

LangChain is essentially the backbone of the modern AI engineering ecosystem. At its core, it's an open-source framework designed to make building LLM-powered applications and agents dramatically simpler. Instead of manually wiring together your LLM calls, memory, tools, and data sources, LangChain gives you modular, composable building blocks that snap together cleanly. Think of it like Spring Boot, but for AI. It handles the plumbing so you can focus on the logic.

Some of the key things LangChain abstracts away for you:

LLM integrations — Swap between OpenAI, Anthropic, Google Gemini, or any other provider with minimal code changes. No vendor lock-in.
Chains — The ability to link multiple LLM calls or steps together in sequence, where the output of one step feeds into the next.
Memory management — Built-in support for both short-term conversational memory and long-term vector-backed memory, without you having to wire it up yourself.
Tool & agent support — Easily equip your agent with tools (web search, code execution, API calls) and define how it reasons and plans using patterns like ReAct.
RAG pipelines — LangChain has first-class support for document loading, chunking, embedding, and retrieval, making it straightforward to build a RAG system on top of your own data.

Tip: LangChain also comes with LangSmith, an observability and debugging platform that lets you trace exactly what your agent is doing at every step, which becomes invaluable the moment your agent starts doing something unexpected.

If you're in the Python world, LangChain is the clear go-to and has the largest community and ecosystem around it. But if you're a Java backend developer like me! someone who lives in Spring and loves OOP; frameworks like Spring AI and LangChain4j bring these same ideas into the Java ecosystem, letting you spin up fully functioning, production ready agents using the design patterns you already know and love.

This covers the bare-bones of modern AI. Below are some useful videos and resources if you're interested in learning more.

DEV Community: shayesta

My insights on What Working at Big Tech Is Actually Like

Most of the design is already done

Your tools will be unfamiliar, even the familiar ones

A lot of the job is understanding, not writing

Debugging is more like detective work

You'll be oriented by firehose

What it adds up to

What Makes a Software Engineer: The Essence of the Job

The word we skip

Why our version is strange

What the job actually is

"So... problem solving?"

The skills nobody interviews for

Who this job quietly doesn't work for

The botanist problem

The thing underneath all of it

Who it is for

The sentence, finally

LangChain4j and Spring AI: The Plumbing to make your Java Apps talk to LLMs

The mental model that makes this click

Demystifying the AI Wave: A Backend Engineer's Guide to LLMs, RAG, and Agents

Step 1: Say hello

Step 2: Stop getting back strings

Step 3: Teach it about your stuff

Step 4: Let it do things

Where MCP fits

The same thing in LangChain4j

Two things worth knowing

Start smaller than feels worthwhile

Syntax is boring: A mental model to learning a new programming language fast!

The Four Core Architectural Pillars

1. The Type System

Static, Dynamic, and Type Inference

Polymorphism

Why Grasping the Type System Early Matters

How to Identify What a Language Offers in Terms of Type System

2. Language Constructs

Control Flow Constructs

Type Declaration Constructs

Object Model Constructs

Access & Visibility Constructs

Type System Constructs

Behavioral & Functional Constructs

Memory & Execution Constructs

Standard Library Constructs

Why This Matters

Semantics

Example 1: What static actually means

Example 2: Null semantics

Example 3: Pass by value vs pass by reference

Why Semantics Matter When Learning a New Language

Idiomatic Usage

Example 1: Building a string with conditions

Example 2: Transforming a list

Example 3: Null handling

Example 4: Scope functions

Why Idioms Matter When Learning a New Language

The Actual Point

The Real Benefit - Pattern Recognition

Looking for the Presence of These Things

Why It Is Faster Than Syntax-First

The Paradigm Caveat: When the Worldview Changes

Internalizing a Paradigm Shift

Choosing a Learning Order Based on the Situation

Demystifying the AI Wave: A Backend Engineer's Guide to LLMs, RAG, and Agents

Table of Contents 🗒️

Where it all starts: LLMs 🤖

1. Vector Embeddings: The AI's Language 💬

2. Transformers: The Brain 🧠

3. Vector Databases: The Filing Cabinet 🗄️

The TL;DR Pipeline:

Making LLMs smarter: RAG

Plugging everything in: MCP

The big leap: AI Agents

A Tale of Two Protocols: MCP and A2A

1. MCP: The Vertical Layer (Agent-to-Tool)

2. A2A: The Horizontal Layer (Agent-to-Agent)

The Architectural Takeaway

Where does this leave us as engineers?

Example 1: What `static` actually means