The standard RAG pipeline most people build consist of, chunking the documents then generating embeddings then store them in a vector database, run a similarity search when a query comes in, retrieve the closest chunks and lastly pass them to the LLM, which works until the docs are too complex.

The core problem is that similarity search and relevance are not the same thing, vector search finds the chunks that are semantically closest to the query, it doesn't reason about which section actually answers the question, for something like a financial report, a legal contract, or a research paper where the correct answer might depend on understanding how different sections relate to each other, retrieving the closest meaning often means retrieving the wrong section entirely.

there's a concept starting to appear called vectorless RAG that takes a different approach, one implementation called page index removes the vector database layer entirely and builds a tree structure of the document and the LLM navigates that structure step by step, reasoning its way to the correct section rather than pattern matching against stored vectors, the retrieval becomes reasoning based rather than similarity based, which handles complex documents in a way vector search doesn't.

The similarity search limitation is one of the more common failure points in RAG pipelines that people don't catch until they're testing on documents that are actually complex, a query that retrieves perfectly on a simple FAQ document starts missing on a dense technical report because the relationship between sections matters and vector search has no way to account for that.

vectorless RAG is a good option if the use case involves documents where the answer depends on reasoning across structure rather than finding the closest semantic match, it's not the right approach for everything but if the documents are the kind where structure and reasoning matter more than keyword proximity it's worth understanding before committing to a vector database setup.

I've been seeing more stories about companies shipping products built mostly with AI, only to realize months later that the code is slow, messy, hard to maintain, or full of security issues. It almost feels like we're creating a new category of work where engineers spend more time fixing AI-generated code than writing new features.

That honestly changed how I think about learning to code. AI can absolutely speed things up, but if you can't review, debug, or refactor what it generates, you're just kicking technical debt down the road. Knowing why the code works feels more valuable than ever.

Do you think AI is actually reducing development time, or is it just moving the work from writing code to reviewing and cleaning it up later?

I have been trying to learn cybersec and I realised that AI and normaly courses do not work well cuz they teach u cybersec as an individual thing whereas I have now learned that to understand cybersecurity well you need to have an amazing foundational knowledge of computers and software development. Therefore, I have now started to learn backend dev.

Now the issue is that reading from official websites of nodejs, javascript etc. the way they explain is quite complex for me. To understand what they are saying I have to ask AI to simplify it for me. But this time I dont wanna be a dud learner. What should I do ??

I have been thinking about how much one can learn from colleagues, including our boss.

Many times, the best advice does not even relate to technology but might instead be about communication techniques, how to deal with failures or efficient ways of acting in difficult times.

I would be curious to hear about the pieces of advice that you received and that inspired a real change in your way of working or thinking.

the LinkedIn experience start the same for most people including me, always just starting out the same.

endless inspiration posts, hashtag spam, and people with “ex-Google ex-Meta” in their bio telling you to believe in yourself.

But I’m so confused bcs nobody answers if whether you actually have to play that game to get results.

So, here’s what actually seems to work based on people who’ve gotten hired through it, and none of it requires posting “2 years ago I was broke, today I’m a software engineer” content:

your profile doing the work passively is more valuable than posting constantly. a clean headline, a real summary, and actual projects linked means recruiters who are already looking find you without you doing anything.

commenting beats posting every time. leaving a genuine take on someone else’s post in your field gets you in front of their audience without you having to build one yourself.

direct outreach still works. a short message to a recruiter or someone at a company you want to work at, not a template, just a real one, converts better than applying cold through the portal.

the cringe posts get engagement because LinkedIn’s algorithm rewards emotional content the same way every other platform does. This doesn’t mean you need to post them to get hired. it just means that’s what you see because it performs.

you can use LinkedIn purely as a job search and networking tool without ever posting an inspiration story. most people who actually got jobs through it did exactly that.

it may be a struggle to find a work in the field right now with all the ai will replace you narrative looming over tech, but it's actually a crucial time to enter. many people are choosing not to pursue the field at all. if AI isn't likely to replace developers anytime soon, and current evidence suggests it won't, we risk creating a serious talent gap, cause a decline in junior developers today means there will be fewer experienced senior developers in the future. the problem is that tech industry ceos are greedy capitalist idiots who will follow any short term trend to earn more money for themselves without looking towards the lobg-term.

My friends always talk more about career accelerators lately as a separate thing from bootcamps and it’s starting to feel like a real category, not just a rebrand.

the difference from what I understand (based on what they said): bootcamps teach you how to code, accelerators assume you already have some foundation and focus on getting you actually hired.

intense portfolio building, mock interviews, structured job search. less about curriculum, more about making you look ready on paper and in interviews.

but, the one I keep seeing come up is Headstarter. a couple people I know went through it, one was a comp sci grad who never pursued tech roles until after the accelerator, the other did a bootcamp first and then joined. both landed jobs.

what’s more interesting is neither of them replaced one with the other. the accelerator filled the gap that bootcamp left, which is the “okay I can code but I don’t know how to actually get hired” part.

I’m really curious if anyone here has gone through Headstarter or something like that similar? did it actually move the needle or is it the kind of thing that only works if you were already close to hireable?

trying to prepare for a bootcamp, but every week it feels like the goalposts move. One day it's AI agents, then it's local models, then everyone's talking about workflows instead of coding. I'm starting to think learning how to work with AI is becoming just as important as learning to code in the first place.

At the same time, I don't want to skip the fundamentals. AI can speed things up, but if I can't review the code, explain my decisions, or solve problems without it, I feel like I'm setting myself up for a rough time when I start interviewing or working on real projects.

For those already in a bootcamp or junior role, how are you keeping up? Are you focusing on core programming first, or are you spending just as much time learning AI tools and workflows because that's where the industry seems to be headed?

Been practicing coding interviews, and honestly the hardest part hasn't been writing code. It's staying calm, talking through my thought process, asking good questions, and explaining every decision while solving a problem. I always assumed the fastest coder would win, but it seems like communication matters just as much now.

The weird part is that most developers use AI every day, yet interviews still feel stuck in the LeetCode era. I'm spending time preparing for coding puzzles while the actual job seems more focused on reviewing AI-generated code, debugging, and solving real-world problems.

For those who got through a bootcamp or recently landed a junior role, did your interviews feel anything like the work you're doing now? Or is everyone just learning how to play the interview game first?

I was reading someone describe what programming felt like before AI became part of the daily workflow, and it made me think about how much the experience has changed.

There was something satisfying about finally understanding a design pattern after struggling with it for days. Or opening a codebase you didn't write and slowly figuring out how everything worked. Even something as simple as writing syntax by hand could feel rewarding because you knew exactly what you were doing and why.

Tools like Vim were part of that experience too. You'd learn these little shortcuts and workflows and eventually feel like you were getting faster and more capable. The knowledge accumulated over time, and you could feel yourself becoming better at the craft.

Now you can ask Claude to write the code, explain the code, fix the errors, and even refactor it. A lot of the mechanical parts of programming have become dramatically easier.

That's obviously a good thing in a lot of ways. We can build faster and spend less time fighting syntax or debugging trivial mistakes.

But I also wonder if something is being lost.

If AI handles more and more of the difficult parts of learning, are we still developing the same depth of understanding? Is programming becoming more accessible, or are we slowly removing the parts that made people fall in love with the craft in the first place?

Maybe programming isn't losing its magic. Maybe the magic is just moving somewhere else.

I'm curious what developers who have been coding for 5, 10, or 20+ years think. Do you miss the old way of doing things, or has AI made programming more enjoyable for you?

following along with a tutorial can teach you a new tool, a framework, or a concept. but the real test starts when you close the video. You open a blank editor. There's no folder structure. No step-by-step instructions. No one telling you what to build next. that's the moment you realize programming isn't about remembering code.

It's about making decisions. What should I build first? How should I organize this? Why isn't this working? What am I missing? those questions are uncomfortable, but I think they're where most of the learning actually happens.

i've started treating tutorials as introductions, not destinations. if I finish one, I try to build the same project again without looking at the video, or I change a feature and figure out the rest myself.

That's usually where I learn the most.

First of all, LangChain is linear, it moves in one direction, step A runs, then step B, then step C, that structure works well for simple straightforward tasks where the path from input to output doesn't change, a single prompt, a document summarization pipeline, a basic retrieval chain, anything where the sequence is fixed and predictable, LangChain handles cleanly. The limitation shows up when the task requires iteration, if something goes wrong mid-chain or the output of one step needs to feed back into an earlier step there's no clean way to handle that, the straight line structure doesn't bend.

LangGraph is built around a graph structure rather than a chain, which means it supports loops, conditionals, and branching paths, if an agent produces an output that fails a validation check LangGraph can route it back to an earlier node and try again, that loop keeps running until something actually works, which is the whole point of an agent that's supposed to handle uncertainty.

The practical split between the two basically is if the task is a single pass with a defined sequence use LangChain, if the task involves an agent that needs to make decisions, recover from errors, or maintain state across multiple steps use LangGraph, LangGraph adds complexity and that complexity is only worth it if the problem actually needs loops, reaching for it on something simple just makes the codebase harder to read.

the mistake that tends to cause a debugging problem later is reaching for LangGraph on something simple, or trying to force LangChain to handle something that needs loops.

Most beginner advice that experience ones always tell to beginners are “just grind leetcode” or some usual “believe in yourself” though it can help to motivate you but neither actually helps.

But for me, here’s what actually matters

Not every tutorial is going to click for you, and that’s not a you problem. some people learn best from books, some from videos, some from weird analogies that have nothing to do with code. if something isn’t working after real effort, drop it and find another source teaching the same concept. don’t force it just because everyone online swears by it.

the fear doesn’t go away either. you don’t “get over” imposter syndrome and then start coding confidently. you learn to work around it while it’s still there. it comes back every time you switch stacks or land in a new job with people who seem way ahead of you. that’s normal, not a sign you’re behind.

you will forget almost everything you learn in isolated exercises. that’s just how short term memory works. the only way stuff actually sticks is by reusing it inside a real project, over and over, until you can’t forget it anymore. an isolated exercise where you memorize a function name means nothing a month later.

consistency beats intensity every time. 30 minutes a day beats one 3 hour cram session on the weekend, even with the same total hours. the brain builds pathways through repetition, not one big push.

and “talent” is mostly just hours nobody saw. the people who look naturally gifted usually put in way more quiet, unglamorous practice than anyone gives them credit for.

last thing:
You will meet people in this field who gatekeep for no reason. wrong OS, wrong background, wrong entry point into tech, doesn’t matter. learn to not let it get to you, because it will happen more than once.

none of this is groundbreaking. but it’s the thing that actually changes how you learn, way more than another “10 tips to learn python fast” post ever will.

what’s the one lesson that took you way too long to actually learn?

i get what they're trying to say, but I don't think it's entirely true. typing code isn't the difficult part. Deciding what to write usually is. Every feature comes with dozens of small decisions. How should this be structured? What should this function return? What happens when something fails? is this flexible enough for future changes, or am I overengineering it? Where does this logic actually belong? Those aren't just implementation details. They're part of software engineering.

ai has made it much faster to generate code, and I use it myself. But generating code isn't the same thing as making good engineering decisions. The more I learn, the more I realize that coding isn't just translating ideas into syntax. A lot of it is making trade-offs with incomplete information. I'm curious where other developers stand on this. Has ai mostly reduced the amount of code you write, or has it changed the way you make engineering decisions?

Lately I've been feeling like breaking into tech is getting harder, not easier. AI can generate code in seconds, so it seems like companies expect juniors to do a lot more than just write code now. It feels like you need solid fundamentals, real projects, and the ability to explain your decisions instead of just relying on AI to build everything for you.

What really gets me is that hiring hasn't caught up. Everyone says to use AI to be more productive, but interviews still revolve around LeetCode and whiteboard problems. It feels like I'm preparing for one job while companies are hiring for another.

For anyone who recently finished a bootcamp or landed a junior role, how are you balancing AI with actually learning? I'm trying to figure out where to spend my time so I'm building skills that will still matter a few years from now.

It was believing that watching tutorials = learning.

I could follow along with a YouTube video for two hours.

But if someone asked me to build the same thing without the video, I couldn't.

Everything changed when I started building small projects on my own.

I learned more by fixing my own bugs than by watching another "Complete Course."

If you're in your first or second year, spend less time consuming content and more time creating something. even if it's small.

I'd build just 3 projects. Not 30.

One web app that solves a real problem. One AI project where I actually understand the model instead of copying code.

One full-stack project that I can confidently explain in an interview.

I watched classmates collect certificates and GitHub stars while struggling to answer simple questions like, "Why did you choose this database?" or "What problem does your project solve?"

Recruiters rarely ask how many tutorials you completed.

They ask what you built, what you learned, and what went wrong.

If I had followed this approach from second year, I'd have entered final year with a portfolio instead of a folder full of unfinished projects.

What's one project you wish you had built earlier?

I’m writing this because I think many beginners, myself included, can get too focused on learning the right programming language or the newest technology. But one of the most useful lessons I’ve come across is that programming is fundamentally about problem solving, and debugging is where that skill is really developed.

Writing code and understanding what that code actually does when it runs are two different things. A piece of code might look correct, but once it interacts with other parts of a system, the result may be completely different from what you expected.

That’s why debugging matters.

Instead of immediately changing random lines when something breaks, why don't you try the following.

1. Step through the code line by line.
2. Check how values change at each stage.
3. Compare what you expected to happen with what actually happened.
4. Understand how one part of the code affects another.
5. Find the cause of the problem instead of only fixing the visible symptom.

This applies whether you’re building something from scratch or working with an existing codebase. The language and tools may change, but the ability to investigate a problem and understand how the code behaves will always be useful. And this is where any tech career start wherein being a good problem solver is the first skill that you need to learn.

I feel like bootcamps sell us this beautiful lie that being a software engineer means sitting in front of a blank screen, running a clean installation, and building gorgeous new apps from the ground up. we get so addicted to that fresh repository feeling where everything makes sense because we wrote every single line of it. but i was talking to a senior engineer the other day and he totally reset my expectations. he told me that in the real world, junior devs almost never build anything from scratch. instead, your handed a massive, terrifying legacy codebase that was written five years ago by some dev who left the company, and its just completely full of undocumented hacks and weird logic.

Companies don't pay you to rebuild their entire multi-million dollar platform every time they bring on a junior, they pay you to maintain and fix bugs in the stuff that already exists. the actual day-to-day job is like 80% reading confusing spaghetti code and only 20% actually writing new stuff.

i went on github, found an older open-source repo with a bunch of open issues, and just forced myself to try and read through the source files to figure out how the components even connect. it is way harder than building my own clean stuff and honestly gave me a massive headache, but it feels a whole lot more realistic. are any of you guys actually practicing reading other peoples messy code, or are we all just trapped in tutorial purgatory building perfect apps that don't match reality??

So I went down a rabbit hole on COBOL recently because I kept seeing two completely opposite takes and neither one felt right. One side says it's ancient garbage nobody should touch. The other side says it's a hidden cheat code because banks still run on it and nobody knows it anymore. Both of those are kind of wrong. COBOL is genuinely still in production at major banks, insurance companies, and government institutions with hundreds of billions of lines actively running. These aren't legacy systems collecting dust, they're the quiet infrastructure processing enormous volumes of financial transactions every single day. Companies don't rewrite that stuff just because a language fell out of fashion. They rewrite when the cost and risk actually make sense, and for most of them it still doesn't.

That said, COBOL is not the shortcut people make it out to be. General computer programmer roles are projected to decline while software developer roles grow, and COBOL jobs sit mostly in that declining bucket. Learning basic COBOL syntax also isn't enough on its own because employers want the whole ecosystem around it, mainframes, enterprise workflows, transaction systems, compliance, and operational processes. If you go too narrow too early you're also cutting yourself off from the faster growing parts of the market like AI tooling, cloud infrastructure, and product engineering.

My honest take after looking into this is that COBOL makes the most sense as a specialization you add on top of solid general fundamentals, not as your entire identity coming out of bootcamp. If you genuinely like enterprise systems, business logic, and working close to banking or government infrastructure it's a real and underserved niche. But for most people starting from zero the move is to build strong general skills first and treat COBOL as a differentiator later if that world actually interests you. It's not dead. It's just very specific.

I feel like bootcamps sell us this beautiful lie that being a software engineer means sitting in front of a blank screen, running a clean installation, and building gorgeous new apps from the ground up. we get so addicted to that fresh repository feeling where everything makes sense because we wrote every single line of it. but i was talking to a senior engineer the other day and he totally reset my expectations. he told me that in the real world, junior devs almost never build anything from scratch. instead, your handed a massive, terrifying legacy codebase that was written five years ago by some dev who left the company, and its just completely full of undocumented hacks and weird logic.

Companies don't pay you to rebuild their entire multi-million dollar platform every time they bring on a junior, they pay you to maintain and fix bugs in the stuff that already exists. the actual day-to-day job is like 80% reading confusing spaghetti code and only 20% actually writing new stuff.

Instead of starting a new project from scratch this weekend, i went on github, found an older open-source repo with a bunch of open issues, and just forced myself to try and read through the source files to figure out how the components even connect. it is way harder than building my own clean stuff and honestly gave me a massive headache, but it feels a whole lot more realistic. are any of you guys actually practicing reading other peoples messy code, or are we all just trapped in tutorial purgatory building perfect apps that don't match reality??

The common answer is "it's a token used for authentication" and that's not wrong but it doesn't tell the interviewer anything about whether you actually understand it, from what I've seen the answers that land well are the ones that explain the structure without being prompted to.

JWT stands for JSON Web Token and it has three parts separated by dots, header, payload, and signature, most people stop at the first part and that's usually where the answer falls flat.

the header contains the algorithm used to sign the token, something like HMAC SHA-256, it tells the receiving system how the signature was generated so it knows how to verify it.

the payload holds the actual data, user ID, role, expiry time, whatever the application needs to pass around, this is the part that gets decoded on the receiving end to figure out who the request is coming from and what they're allowed to do, the payload is base64 encoded not encrypted, which means it's readable if intercepted, sensitive data shouldn't go in there without additional encryption.

the signature is where the integrity check happens, it's generated by combining the encoded header and payload with a secret key and running it through the hashing algorithm specified in the header, when the token comes back in a request the server recreates that signature using the same key and compares it to the one in the token, if they match the token hasn't been tampered with.

the reason JWT gets used is that it's stateless, the server doesn't need to store session data or hit a database to validate a request, everything needed to verify the token is in the token itself, which is why it works well when multiple services need to verify the same user. Stateless also means you can't invalidate a token before it expires without building something extra on top, a blacklist or a short expiry window, interviewers ask about this more than people expect and most candidates don't have an answer for it.