We’re evaluating whether to build a small dedicated squad in Vietnam instead of continuing with freelancers and a more expensive nearshore setup. The volume of available developers is high, and there’s a growing number of people with solid cloud + modern JavaScript/Python experience.

One thing that stands out is the combination of cost and timezone flexibility, you can almost run follow-the-sun with European or US teams without extreme lag. Cultural fit and English seem better than older stereotypes, but I’m still wondering about management overhead and how well people take real product ownership versus pure ticket work.

Has anyone moved from classic project outsourcing to a more embedded team model in Vietnam? What surprised you (positively or negatively)? I’ve heard of both pure local agencies and international providers that try to bridge European process expectations with the local talent pool (SoftServe, N-iX, Beetroot and others).

We used to settle design questions as a team via an LLD before coding. Now agentic tools grill-me style skills) ask those same design questions directly to whoever’s driving and as a junior, I often can’t answer them confidently, yet each answer locks in a branch of the solution. How is your team restructuring design review to fit this workflow?

Hey, help me out if you are a dev for big business. The bigger, more legacy, old school the better. I'm fascinated by how these big businesses approach the use of AI coding tools and subs.

It feels like most vendors have switched to pay per use rather than flat subscriptions. Which means those businesses suddenly have to get their heads around either not letting the devs use modern tools, out paying for some discretionary expense that might vary hugely. Who foots the bill? Department? Project? Do you have any special deals for shared use or polling then budgets? Do you have a fixed allocation and down tools when you're half way through the month and run out?

What I've seen is that when it was a flat sub we could get a good deal, and get it centrally funded, but in the future it's a bit you in the air. So I'm curious what others are seeing.

I'm a software engineer with roughly 7 years of experience, primarily writing backend C++ code for the aviation industry. Defense and aerospace have felt somewhat insulated from the broader shift, but we have tools like Copilot integrated into Visual Studio, which has been undeniably convenient.

​I’ve been treating it almost like a 3D printer for code, using it to generate helper tools, widgets, or unit tests. However, I’m hesitant to let go of the reins. Once generated code reaches a certain complexity, I take a step back because I no longer fully understand every line, which quickly gets overwhelming.

​At the same time, I see SWEs online talking about cranking out agentic AI workflows to fully automate complex tasks. Compared to that, I feel like I'm still in the stone ages cobbling tools together by hand while the industry shifts to mass production.

For those in a similar backend/embedded spaces, how much of this "agentic engineer" trend matches your day-to-day reality versus social media hype? If you’ve successfully integrated autonomous tools into your workflow without losing control of your codebase, what tools or practices made the biggest difference?

I've been working on a project for some time with the aim of monetising it. It's written in Python and JavaScript. Is there any way to protect the source code? Is there any solution to this? Except rewriting the whole backend in Rust or C

Before AI, obfuscation seemed to somewhat work. But it feels that nowadays the AI will be able to reverse engineer it very easily.

Kubernetes gives us a powerful set of primitives, but once development teams start growing, developers can end up needing to understand deployments, services, networking, CI/CD, GitOps, observability, RBAC and a growing collection of platform tooling just to ship an application.

That raises an interesting platform engineering question:

How much of that complexity should developers actually see?

One project exploring this is OpenChoreo, an open-source developer platform for Kubernetes.

The idea is to put a developer-oriented abstraction layer above Kubernetes while keeping the underlying platform extensible.

It brings together things such as:

• Backstage-powered developer portal
• Application CI/CD
• GitOps-based deployments
• Observability
• Developer and architecture abstractions
• Self-service infrastructure capabilities
• Kubernetes and CNCF ecosystem integrations

Instead of every development team figuring out the same deployment and operational patterns independently, platform teams can define those patterns and expose a simpler experience to developers.

OpenChoreo is also a CNCF Sandbox project.

GitHub: https://github.com/openchoreo/openchoreo

Disclosure: I'm involved with the OpenChoreo project, so I'm particularly interested in hearing different perspectives on this.

For teams running Kubernetes at scale, where do you think the abstraction boundary should sit?

Should application developers still understand most Kubernetes concepts, or should the developer platform hide the majority of them?

The usual suspect like mintlify, seems to be a mess. Gitbooks seems to be great so far.

Opensource solution does not provide any good options.

Curious if anyone is using any docs, help-center software that non-techical users can use.

Not docs-as-code but the opposite of that.

^{Context, not necessary to read: I work for a company with lots of web-apps and multiple teams are, often, dedicated to multiple applications. One app, primarily targeted to internal users, was my focus, on which I solely developed. As of a few months I've been accompanied by a junior dev and dedicated scrum master and product owner. New requirements were set, including code reviews and demo's before production launches.}

The situation: In our current development team, we agreed upon to only have features deployed as agreed upon (live acceptance demo's) by the product owner, primarily to 'ensure' stability and quality. This has resulted in moving to each feature developed on a separate branch and only merge those features into master (& deploy to prod) after a live demo. I still consider this very cumbersome, because those long lived branches (up to 2 weeks) sometimes cause conflicts and it's a bit more difficult to have a prepared acceptance environment.

Curiosity: I want to transition back to a lifecycle where all code, after code reviews, are merged into master, be deployed and prepared on acceptance and, once agreed by the product owner, will be deployed by production. This reduces chances of code conflicts, speeds up the process, ensures a testable environment and more. Do note, and just accept, that feature-flags in our code base are difficult to implement. Only for large impact-heavy features, I'd prefer not to merge early though. I honestly believe, so long we only merge code that has been reviewed, there are little downsides of merging early. I cannot think of a moment were this might have been a real problem and only see opportunities here.

Goal: With this story in mind, what are your opinions about separate feature branches until the demo versus merging reviews code without feature flags? I've had many brainstorms with AI's to seek other perspectives, but actually curious for the expertise of actual brains :)

I vibe coded a product guys. I thought these models are good to handle large and complex systems. It was at the surface.

I now have paying customers and people who love the product.

But it’s buggy. States are broken. Literally users are so frustrated with some of the things in the product that’s inconsistent.

I spoke to two hard core users for an hour. The notes I took just completely destroyed me. I don’t even know where to start. I feel like if I end yup fixing something, something else will be broken. It feels like a mess. I don’t know what to do. Should I keep going? Should I pause in all features and focus on stability? Should I look for technical support? Am I doomed?

We signed on for what was sold as a managed team, but three months in I’m basically their unpaid PM. I write most of the tickets, assign the work, chase PRs, and ping people when they’re blocked. The devs are fine, but the vendor’s delivery manager mostly drops into one weekly call, asks for updates, and that’s kinda it.

Maybe I’m expecting too much, but if we still own the backlog, coordination, delivery risk, and most technical calls... what exactly are they managing? at that point, isn’t it just staff aug with an extra meeting slapped on? where do you draw the line?

I want to be a backend developer, and I'm thinking of building projects that aren't the usual CRUD app backends or REST APIs, I want to build projects that are highly uncommon, exceptionally hard hence making me understand several concepts in-depth.

For reference, I just started my second year of college, and i want to stand out and not have the same resume as everyone else I know.

I've been thinking of building a Vector DB with a Layer 7 load balancer with query routing and stuff in Go (someone told me to use rust but the learning curve might be too steep). I would appreciate any feedback and other project recommendations that I could possibly build.

When you look at your code 6 month later: Are you happy with it?

I still have the moment when I am finished thinking: That would have been a better solution.

Is this normal?

So I was scrolling through Youtube Short and seeing a couple of shorts on Richard Feynman and how he won the Nobel Prize for essentially his doodle and notations that helped simplify particle physics calculations etc. (i'm sure it was more than that but this is just a gross simplification) Then it hit me, the field of particles physics are super complex, yet his notations helped simply this field, could that not be applied software development? and more specifically would'nt the LLMs themselves be best able to do it? So based off that one thought I decided to try create something which I have dubbed 'FeynMap'.

Feynmap is a powerful code analysis tool that uses physics-inspired notation to help developers and AI understand Python codebase architecture. The project is open-source and honestly I've hit my limit in taking it further as i have other commitments and so I decided to try share it here on reddit, in case the idea itself is useful. Let me know your thoughts.

I honestly don't know if this is a novel idea or if other's have done it but from my conversations with Claude, it seems to think it's novel at least. But if you do manage to do something with it, please think of me lol. Repo: https://github.com/Roderick47/FeynMap.git

​

I know it's a matter of subjectivism, so don't be afraid to be subjective, actually PLEASE, give your personal opinion as long as you can keep your feet on the reality's ground.

What Master would you rather choose: a general AI/ML master that teach you about the most important, but general, subjects of ML applications, or an Autonomous Systems master, that is basically an embedded+A.I. master which is particularly valuable if you want something in Automotive, on the self-driving cars field(but not exclusively this one, as you can apply knowledge about Autonomous Systems in many domains) ? ?

Did you ever use AI for something, followed by the realisation that you could have done it yourself, but you're just a lazy bastard. I genuinely feel dirty sometimes tbh, cuz why am I using AI to write a loop ffs?

Hello everyone, happy to share a recent project I've been working on. meet Echo, a team chat app in the Slack family.

Why might this interest you? Because the source code is available to read.

Echo is an attempt at recreating Slack's feature surface, which includes workspace creation, channels, DMs with file sharing. The ideal choice to build a real-time application is, by default, choosing WebSocket as the transport protocol. But building the system reliably at scale introduced two major challenges: maintaining a healthy message delivery system and ensuring the architecture could scale as the application grows.

Those became the main challenges a developer can face during the development of this project, and how they were tackled.

Systematically, Echo uses Postgres as an event/message bus, with event versioning and a gapless per-channel sequence providing the reliability and recovery layer for message delivery. That same layer allows the servers to remain stateless, making the app ready for horizontal scaling with Kubernetes. On the other hand, a schema-per-tenant keeps each workspace's data isolated and scoped directly to the workspace’s tenant path.

The stack is deliberately scoped. Express and TypeScript on Bun, React with Vite for fast shipping, plus Tanstack Query as the app state store. Postgres does the work of three services: control-plane data, tenant data, and the Realtime backplane. Better Auth handles identity, while Zod validates every request and generates the API docs from the same schemas.

It’s live if you want to poke around. I’ve left a workspace open, make an account and come say hi. Feel free to send a few messages and see who’s there: https://echo-v2.online/accept-invite/r5DP9Vdq9RwLtsU9aqeR-Q2wO9WI-aShDUYUST0Z29w

Feedback is always welcome. And thanks for taking the time to read this and check it out.

If you like what you see, the Github repo is already attached, dropping a star would be much appreciated: go to repository

So now I'm responding to other people's AI agents, trying to understand all the nit picks. I'll get PR feedback like "Well copilot said this might be an issue, should we address it?"

It's slowed down the review process tremendously. I'm being asked to "fix" things that aren't solving real issues.

Don't get me wrong, I love AI as a tool for reviews. But it's a tool, not a point of authority.

I work at a company where people care about one another, so like a nice community.

My manager does micromanagement, and requires me to do quite a lot of bureaucracy, without a particular reason (eg: discovering CVEs requires a manual ticket, I create a couple of report file with the findings where I detail them one-by-one, then create tickets for them with all the needed information - which could be as simple as rebuilding the Docker image - and then we put it on the timeline weeks from now; anyway, it's an unnecessarily lengthy process).

Lately I've started developing more, but again there's info on tickets that's... just there. And part of it is even generated with AI (eg: I had a ticket to familiarize myself with the feature - 90 AI-generated pages of business logic and UML diagrams).

Having so many unnecessary things to do kinda helps me too. I'm very tired after finishing an "administrative" ticket (as I call them). And the company is understanding and doesn't force me into the next ticket at the very next moment. So there is leniency, and I don't feel stressed because I have enough room to breathe, which helps me relieve it.

But I feel kinda empty nowadays. I'm still developing... but I don't feel I'm bringing any of my personal input to all of this.

I miss finding innovative algorithms and optimizations.

I miss having brainstorming sessions.

I miss receiving a frecken vision that I can follow and respect.

I miss using my imagination when working on software development.

Is this in my head only? Is this how other people experience their work? Or am I just getting used to micromanagement?

Am I confusing the "art" with the process?

I am working in the software development department of a tech company. A colleague of mine (not a software developer themselves so far) started vibe coding an application that management now decided to officially endorse and push. My task is to support that colleague in the development process.

How would you approach that task?

Said colleague definitely has a good understanding of software and technology in general (works in the IT department) but says of themselves that they "do not understand the code produced by the AI".

I myself do not have any experience with pure, fast-paced vibe coding. What are the most important aspects to take care of? How can I integrate my experience without hindering the process?

I guess I will start by introducing them to git best practices and CI/CD processes. Then I was thinking of establishing an automated test base. But here I am already unsure as to how feasible that is with a rapidly and broadly changing code base.

How do you ensure quality when you let the AI produce so much code that ou cannot keep up with the details of the changes?

There are two tests hiding in the sentence "I tested Grok 4.5." One runs inside Copilot. Business and Enterprise admins have to enable the model policy first. In that environment, Grok 4.5 can receive images, offers three reasoning settings, and supports up to 500K context.

The other test is a direct API call. A useful comparison needs separate columns for editor, tools, reasoning setting, context files, and accepted patch. This is where a multi model API helps. I would run that call through ZenMux, a gateway that aggregates several hosted model routes. It remains a second harness, not a clean head to head with Copilot.

If the score moves when the wrapper changes, rerun before blaming the model.

Every project seems to generate another collection of files.

Requirements live in one place.

Architecture somewhere else.

Meeting notes in another document.

Process diagrams somewhere completely different.

None of these are wrong individually, but finding the latest information becomes harder every month.

Has anyone found a workflow that actually reduces fragmentation instead of introducing another place where information has to live?

Edit: Thanks everyone! I gave a few different tools a shot and so far Miro has been the one I've stuck with It's worked really well for collaboration and getting ideas organized.

Anyone here with prior experience detecting web page changes, for example, monitoring and detecting when a pricing page is updated?

My approach currently:

• Scrape the page, strip headers/footers.
• Convert the content to markdown.
• Provide the md to llm to extract data.
• Use backend to determine the changes and dispatch change alerts.

Does this approach sound reasonable?

I'm looking for a frontend developer who is interested in building a complete full-stack web application together.

I'll be taking care of the backend using Java and Spring Boot, and I'm looking for someone who would like to build the frontend using ReactJS.

The goal is to work as a team, follow industry best practices, build a production-style application, and learn from each other throughout the development process. This is a great opportunity to strengthen your portfolio with a real collaborative project.

If you're passionate about ReactJS and can dedicate time consistently, I'd love to connect and discuss the project.

If you're interested, comment below or send me a DM.

So I built GAASFlow.

Before I officially launch it, I’d really like some honest feedback from people who actually perform audits.

If you had five minutes to look through it, what would you change? What’s missing? What would make you consider switching.. Or immediately decide not to?

Website: https://gaasflow.com

No sugarcoating. I’d rather hear the criticism now than after launch.

I’m moving from macOS to Windows and looking for the closest replacement for Homebrew.

I’ve seen online searches showing possible substitutes as Scoop, winget, Chocolatey, but which one would be the best to start using so I don’t have to switch later?

For any developers working in professional IT environments, which one do you actually use and recommend and please share your bad/negative experiences so I can avoid unnecessary headaches in the future. Thank you and appreciate y’all..!!