We have a JSON mode assistant that looked reasonably priced until I split the cost by attempt instead of by request. Unfortunately, I found that a single missing required field triggers a full retry, so the model rereads the entire system prompt, duplicated retrieval chunks and the whole input before regenerating every field. An uncached timestamp near the top also breaks prompt caching. The first attempt often contains 99% of the right answer but we throw it away and buy another one because a nullable field didn’t arrive. 

We are testing schema repair, stable prompt prefixes, idempotency keys and token attribution by attempt. I still don’t like trusting partial JSON but full regeneration for one absent field feels absurd.

How are you handling structured output failures without turning a tiny validation error into two full generations?

I’m a 2nd-year B.Tech CSE student from a Tier-3 college in India, and I’m confused about which backend path to focus on:
Java + Spring Boot
Python backend (FastAPI/Django) + AI
I’ll graduate in 2029, so I want to choose something with good fresher job opportunities.
If you had to choose between these two in my situation, which one would you pick and why? Also, which one do you think will have better demand by 2029?
Would really appreciate honest opinions from people already working in the industry.

I've been away from programming for a while due to some psychiatric reasons. My frontend knowledge is limited to just CSS and HTML, and I'd previously worked with .NET MAUI and Blazor. I don't enjoy frontend at all it's not an area I like I'm much more drawn to backend and API work. I wanted to ask what level of frontend knowledge would be enough to get by, given that I focus on backend.

I’ve had tasks where Claude Code/Codex feels almost magical - something that would've taken me a couple of hours gets done surprisingly quickly.

And then there are other tasks where I spend the whole time going:

“Don’t touch that.”

“That already exists.”

“We don’t do it that way here.”

“Look at how we solved this in the other service.”

“Run the tests before saying it’s done.”

“No, that’s not actually what the ticket is asking.”

By the end, I sometimes wonder whether I saved any time at all.

For people using coding agents regularly on real production codebases:

What was the last task where you ended up doing a lot of steering? How did you fix it ?

What was the agent getting wrong or missing?

Did you change anything afterward - prompts, claude md, agents md, skills, rules, scripts, MCPs, workflow, etc. - so you wouldn’t have to do the same steering again?

I'm much more interested in actual recent examples than whether AI coding is good/bad in general.

Title: Best way to chunk and structure data for RAG/embeddings?

I'm building a knowledge base for RAG and I'm looking for practical advice from people who have done this in real projects.

How do you usually handle:

• Chunking: fixed size, semantic, sections/headings, parent-child, etc.?
• Metadata: what fields are actually useful for filtering/retrieval?
• Hybrid search: do you combine semantic search with BM25/keyword search?
• Reranking: do you retrieve from both and rerank the combined results?
• Updating knowledge: how do you replace/version old information?
• Scaling: how do you structure things so adding new types of information later is easy?

I'm particularly interested in systems where the knowledge base keeps growing over time.

What approach worked best for you, and what would you do differently if you were starting again?

Comme j'ai commencé à apprendre le développement à peu près à cette époque, j'ai dû tâtonner un bon moment avant de trouver la pile technologique qui, selon moi, correspond le mieux à mes besoins et au type de projets que je réalise.

J'ai commencé à apprendre le développement avec AdonisJS.

À l'époque, il y avait déjà de nombreux cours créés directement par l'équipe du framework, ce qui était vraiment idéal pour apprendre toutes les bases du développement web.

Naturellement, j'ai ensuite commencé à utiliser AdonisJS pour réaliser mes premiers projets.

Il y avait une pile technologique en particulier que j'ai trouvée très pratique : AdonisJS + Inertia + React.

Elle me permettait d'avoir une seule application, avec le frontend et le backend intégrés.

Le premier obstacle qui m'a fait abandonner AdonisJS, cependant, a été le déploiement. À l'époque, je devais utiliser Docker et gérer moi-même une grande partie de l'environnement, le déploiement, etc.

Et je n'avais tout simplement pas envie d'y consacrer du temps.

Je voulais créer des projets et des SaaS, pas passer mon temps à gérer Docker et l'infrastructure.

Je souhaitais vraiment me rapprocher au maximum d'un environnement où je pourrais déployer mon projet et c'est tout.

Puis, l'IA prenant une place de plus en plus importante dans mon flux de travail, un deuxième problème est apparu : AdonisJS n'était pas assez répandu, et les IA avaient donc beaucoup plus de mal à l'utiliser.

Je suis donc passé à Next.js et Supabase.

Et là… honnêtement, même si tout le monde utilise Next.js, je n'ai jamais vraiment compris l'intérêt d'ajouter autant de complexité à mon architecture.

Composants serveur, changements constants, comportement implicite du framework…

Je me souviens notamment des changements concernant les middlewares/proxys où, lors du développement avec l'IA, personne ne comprenait vraiment ce qu'il fallait faire. Moi non plus, et parfois l'IA non plus.

Et c'est probablement ce qui m'a le plus gêné avec Next.js : tant de choses sont implicites.

On est censé savoir que placer un fichier spécifique à un endroit précis déclenchera un comportement spécifique, qu'une partie s'exécute sur le serveur, qu'une autre fonctionne différemment, etc.

Quand on développe beaucoup avec l'IA, je trouve que ça devient vite agaçant, car une grande partie du travail repose sur des suppositions.

C'est pourquoi j'ai fini par passer à TanStack Start. TanStack Start couvre globalement les mêmes besoins que Next.js : React, routage, SEO, fonctions serveur, backend, etc.

Mais je le trouve beaucoup plus explicite.

Quand un problème survient, il est bien plus facile de comprendre pourquoi et comment.

Et pour le développement assisté par IA, je pense que cela fait une énorme différence.

Cela résout aussi précisément le problème de déploiement que j'avais au début.

L'intégration avec Cloudflare est excellente et aujourd'hui, je n'ai quasiment plus rien à faire pour déployer correctement mes applications.

Je peux me concentrer sur ce que je veux vraiment faire : créer des produits, au lieu de gérer l'infrastructure sous-jacente. Aujourd'hui, ma pile technologique pour le développement SaaS est la suivante :

TanStack Start + Supabase.

Pour le développement, je peux utiliser quasiment n'importe quel outil d'IA de création de code : Claude, Codex, etc.

TanStack possède désormais d'excellentes capacités et une documentation très claire. Et surtout, grâce à l'explicité du framework, une IA peut lire le code et comprendre très facilement son fonctionnement.

Alors qu'avec Next.js, j'avais beaucoup plus souvent l'impression qu'il devait deviner. Voilà donc comment mon architecture technique a évolué :

-> AdonisJS + Inertia + React -> Next.js + Supabase -> TanStack Start + Supabase

Au final, mon critère principal n'a pas vraiment changé depuis le début : je veux consacrer le moins de temps possible à la gestion de l'architecture et de l'infrastructure, et le plus de temps possible au développement de mes projets.

Et pour l'instant, TanStack Start + Supabase est probablement l'architecture avec laquelle je me sens le plus à l'aise.

So I'm in a second year btech students CSE,,,, so there is anyone who is a taking a batch of apna college in which Web development is completely taught so help me yaarr bhaiyon muze bhi Koi access de do yaarr... Muze kharidne ka Mann nhi hai anyone here jo de sakte ho.......

Hi everyone, I will be graduating next year. I have mostly worked with FastAPI along with Postgres, SQLAlchemy, Alembic. I have worked with EC2, Nginx reverse proxy, redis, git/github, Docker, integrating LLM api callling endpoint in my projects.
what technologies i should learn now to make my cv more attractive. I have applied for 60+ jobs, but not getting any responses.

​

Hey everyone,

​I'm in my final year of computer science and aiming to break into backend engineering. I haven't built any substantial projects yet, and I want to spend the next few months building a solid foundation instead of following generic clone tutorials.

​For those working in backend roles:

​What core backend concepts (databases, concurrency, API design, caching, system design basics) should I prioritize first?

​What kind of project architecture or problem-solving shows real competence on a junior resume?

​Which language/ecosystem would you recommend investing in right now for someone starting out?

​Any guidance or honest roadmaps would be greatly appreciated!

Okay so i'm a beginner and i have some questions ,i would appreciate getting answers from someone who's been into backend and also tech honestly from a long time,someone experienced or knowledgable about the domain.

1.Should i go with BACKEND or AIML?my aim is to land a high paying job honestly,and just asking regarding a development perspective,which would be the best?my targets would be MAANG and above companies(regarding the pay).Just wanna know what field would be more valued from a dev pov and hiring pov(odds of landing something high paying)

2.How do i start backend,i am going with python-fastapi,i want to pace up the process leading to inclusion of more PROJECTS and OPEN SOURCE CONTRIBUTIONS as well.Suggest me something that leads to more on the side of actually developing and doing the work.Also don't reccommend me the roadmap.sh website,i myself found it quite complicated or intimidating to see such a large list of things to do...

3.If you have any other suggestions as well,please do tell me i am very much open to listen to them.

Although just keep it development related only.

Ultimately my aim is to be a great engineer and earn money atleast for my initial years honestly.

I'm currently working on a knowledge base that will use embeddings for semantic search / RAG, and I'm trying to decide on a good long-term strategy for splitting, storing, and retrieving information.

I'm especially interested in systems where the knowledge base keeps growing and changing over time, rather than a fixed set of documents that gets indexed once.

A few things I'm trying to understand from people who have implemented this in real projects:

• How do you decide what should be a single chunk?
• Do you chunk mainly by token/character count, paragraphs, headings/sections, document structure, or semantically?
• Do you prefer smaller independent chunks or larger chunks that preserve more context?
• Do you use parent-child chunking, hierarchical chunking, or any other multi-level approach?
• How much overlap do you normally use between chunks, if any?

I'm also very interested in metadata:

• What metadata do you store with each chunk?
• For example: topic, category, subcategory, source, document ID, section, date, author, entity, version, permissions, etc.
• Which metadata fields have actually been useful for retrieval/filtering, and which ended up being unnecessary?
• Do you use metadata filtering before vector search, after retrieval, or both?
• How do you design the metadata schema so that adding new types of information later doesn't become painful?

Another area I'm trying to understand is the combination of semantic search and keyword search.

Do you rely mostly on vector similarity, or do you combine embeddings with something like:

• BM25 / full-text search
• exact keyword matching
• metadata filters
• entity matching
• reranking
• query expansion / rewriting

For those using hybrid search (semantic + keyword), how do you combine the results?

For example:

• Run semantic and keyword retrieval separately and merge the results?
• Use a weighted score between BM25 and cosine similarity?
• Retrieve candidates from both and use a reranker?
• Change the weighting depending on the type of query?

I'm particularly curious whether hybrid search helped with things like names, IDs, technical terms, acronyms, exact phrases, dates, or numbers, where pure embeddings sometimes don't perform as well.

Also:

• Do you keep everything inside one vector index/database or separate information into collections, namespaces, categories, or domains?
• How do you handle information that gets updated later?
• Do you delete and re-embed the old chunk, version it, or keep historical versions?
• How do you handle duplicate or conflicting information?
• What structure has made it easiest to add completely new information later without having to redesign or re-embed the whole knowledge base?

I'm less interested in theoretical "optimal chunk size" numbers and more interested in what has actually worked in production or real projects.

If you've built a RAG/embedding-based system that has grown over time, I'd really like to hear:

What architecture/chunking/retrieval strategy did you start with, what problems did you run into, and what would you do differently if you were starting again today?

I'm currently working on a knowledge base that will use embeddings for semantic search / RAG, and I'm trying to decide on a good long-term strategy for splitting, storing, and retrieving information.

I'm especially interested in systems where the knowledge base keeps growing and changing over time, rather than a fixed set of documents that gets indexed once.

A few things I'm trying to understand from people who have implemented this in real projects:

• How do you decide what should be a single chunk?
• Do you chunk mainly by token/character count, paragraphs, headings/sections, document structure, or semantically?
• Do you prefer smaller independent chunks or larger chunks that preserve more context?
• Do you use parent-child chunking, hierarchical chunking, or any other multi-level approach?
• How much overlap do you normally use between chunks, if any?

I'm also very interested in metadata:

• What metadata do you store with each chunk?
• For example: topic, category, subcategory, source, document ID, section, date, author, entity, version, permissions, etc.
• Which metadata fields have actually been useful for retrieval/filtering, and which ended up being unnecessary?
• Do you use metadata filtering before vector search, after retrieval, or both?
• How do you design the metadata schema so that adding new types of information later doesn't become painful?

Another area I'm trying to understand is the combination of semantic search and keyword search.

Do you rely mostly on vector similarity, or do you combine embeddings with something like:

• BM25 / full-text search
• exact keyword matching
• metadata filters
• entity matching
• reranking
• query expansion / rewriting

For those using hybrid search (semantic + keyword), how do you combine the results?

For example:

• Run semantic and keyword retrieval separately and merge the results?
• Use a weighted score between BM25 and cosine similarity?
• Retrieve candidates from both and use a reranker?
• Change the weighting depending on the type of query?

I'm particularly curious whether hybrid search helped with things like names, IDs, technical terms, acronyms, exact phrases, dates, or numbers, where pure embeddings sometimes don't perform as well.

Also:

• Do you keep everything inside one vector index/database or separate information into collections, namespaces, categories, or domains?
• How do you handle information that gets updated later?
• Do you delete and re-embed the old chunk, version it, or keep historical versions?
• How do you handle duplicate or conflicting information?
• What structure has made it easiest to add completely new information later without having to redesign or re-embed the whole knowledge base?

I'm less interested in theoretical "optimal chunk size" numbers and more interested in what has actually worked in production or real projects.

If you've built a RAG/embedding-based system that has grown over time, I'd really like to hear:

What architecture/chunking/retrieval strategy did you start with, what problems did you run into, and what would you do differently if you were starting again today?

I’m working on a Kotlin/Spring Boot backend that still has an older JHipster using Kotlin (KHipster) setup around it.

The problem is that this is starting to hold us back. The KHipster version is several years old and not active maintained - 4 years ago was the last update - upgrading it looks pretty painful and it also makes moving to newer Spring Boot versions waaay harder than it should be.

At the same time we want to improve the architecture itself.
Right now quite a lot is still handled through cron jobs and fairly tightly coupled application logic.
I’d like to move more towards event-driven processing over time, potentially using Kafka or RabbitMQ depending on the use case and Redis for things like caching/short-lived state where it makes sense.

So I’m basically looking at two options:
1. Upgrade/replace the old JHipster setup, keep the existing backend, and modernize it piece by piece.

1. Start a clean backend (maybe in Typescript because that is what we mainly use for our other products and all frontends) and gradually move functionality over using something like the strangler pattern.

The second option sounds cleaner, but obviously means running old and new code alongside each other for quite a while. The first option potentially means spending a lot of time untangling framework/generator decisions before we can actually improve the architecture.
For people who have dealt with similar Spring/JHipster legacy projects: which route would you take?

Also, is there anything in the Spring/Kotlin ecosystem you’d consider a good modern replacement for the useful parts of JHipster, without bringing in another big opinionated layer that we’ll regret five years from now?

I work in DevOps mainly handling CI/CD, cloud infra, and Linux servers. I know basic scripting and programming, but I want to get a solid grasp of backend development, APIs, and distributed systems.

Since most cloud-native tools are written in Go, I was planning to learn it for building APIs and understanding platform architecture.

For people who moved from infra to backend, was Go a good first backend language, or should I stick to something like Python before touching Go? Also, what kind of initial projects helped bridge the gap best?

I first required to share my .env file with my team. With a lot of surfing I then realized you can drop using .env files entirely which is a better method. It helps with security and leaking your secrets such as API keys. There are so many services for this. Which service or method should I choose which lets me handle my secrets safely and share them to my team members?

​

I started my roadmap with ML, focusing on Mathematics, Python, MySQL, and a lot of ML algorithms. Recently, I've started questioning whether I'm missing a major part of the foundation: software engineering/backend development. And honestly, I wanna chase both. But something at this point doesn't feel right. I had my roadmap set and ready, and I was very passionate about learning this and continuing it as a career. But after researching a bit about backend development, the intersection and relationship between the two has driven me really crazy.It's exceedingly overwhelming at this phase of my life. I had kind of gotten a grip on ML, but backend coming into the picture has really ruined my mindset around whatever I had planned. I had planned many projects and topics to discover, and now I'm seriously considering pursuing backend development too. But I'm having a hard time trying to combine these two in my roadmap. I can't seem to connect the topics in a way that lets me learn them properly.

My straightforward question is: should I drop backend development and focus on my initial roadmap, should I bridge the two and learn both, or should I drop machine learning completely,which I seriously don't want to do?

If I do bridge them, how much of backend am I actually supposed to learn?

I know I sound stupid and unready for this world, but please help.

Éstoy interesado en entrar a este mundo pero no sé que elegir alguien me de su opinión mejor si es un programador

I’ve been cleaning up the authentication setup I reuse across Spring Boot projects and one part I’ve spent some time on is refresh-token handling.

The setup I ended up with is roughly:

• short-lived JWT access tokens
• opaque refresh tokens
• only the refresh-token hash stored in the database
• refresh token rotated every time it is used
• previous token invalidated after rotation
• Spring Security OAuth2 Resource Server handles JWT validation

I also kept passkeys/WebAuthn as an optional authentication method rather than coupling it to the core JWT flow.

For people running similar setups in production, I’m curious about a few things:

Do you rotate refresh tokens on every refresh?

Do you keep a token family/session record so reuse of an old token can invalidate the whole session?

And at what point do you think this starts becoming too much infrastructure for a normal Spring Boot application?

I’m trying to keep the implementation fairly boring and rely on Spring Security wherever possible, so I’d be interested in how others approach this.

I think I’ve hit the limit of what I’m getting out of freeCodeCamp.

Worked through a decent chunk of it and the certifications stopped feeling useful around the middle of the second one. I can pass the checkpoints but that doesn’t always mean I actually remember the stuff.

Looking at freeCodeCamp alternatives now and I keep seeing boot dev, the Odin Project and Codecrafters.

My end goal is Backend. I’m comfortable with python but I’m pretty shaky with databases and servers.

For anyone who has used these, which one actually helped you understand what was going on instead of just following exercises?

I was viewing a CORS explanation video and I noticed that they had a different web server application for the frontend as well. In my project, I have a single web server application which serves both the frontend pages and handles backend APIs. I realized that this dual web server architecture created by frameworks like Vite is only for development and only a single web server exists in production, but that doesn't mean it is like this for all applications, especially if you aim to design a highly scalable architecture. Large platforms like YouTube can have so many separate web server applications for all their different services than having a single application.

I am talking about a single web server application, not a single server itself. Horizontal scaling isn't limited, but changes when you divide your application into multiple applications. YouTube can just scale a monolithic application but that forces them to add all capabilities together for each system. This can create fragmentation and unnecessary infrastructure space. One application might be more CPU heavy while the other is database heavy. Maybe you need to scale static file serving but not need database scaling and if do that, the databases could take significantly more resources than you need.

If I do create a separate frontend application and that heavily relies on the backend (such as for database), then it just creates lot of unnecessary overhead.

I should start with a single application but the point is to create a scalable architecture where you can make changes without rewriting your whole codebase. And you achieve that my defining abstractions.

So how should I code my application so that in future if I want to move some services into a different web server application, it requires minimal changes?

A worker or upstream API can time out after accepting work but before returning confirmation. Marking the operation failed invites a retry that may duplicate the side effect; marking it successful hides uncertainty. What state model do you use for this gap? A robust design seems to need an idempotency key, an explicit unknown or reconciling state, a way to query the downstream system, and a timeout after which a human or compensating action takes over. How do you expose that state to callers without making every client understand the internals of the job system?

Java

Spring / Spring Boot

APIs REST

SQL

JPA / Hibernate

Git

Maven / Gradle

JUnit

Docker

SOLID

Patrones de diseño

Mockito

Testing de integración

OWASP

JWT

OAuth2

Kafka / RabbitMQ

Redis

CI/CD

Que opinan si estudio eso es buena carrera? O ay mejores áreas de programación,, aclaro recién inicio en esto que opinan viejos sabios vírgenes no se q es código aún XD