Where do the AI-platforms exist in the stack vertical of an application?

Historically, we refer to our tech stack and base its sorting on how much a particular runtime/framework is going to be customer-facing vs internal. For example,

1. A mobile application that allows users to save the links to read later and also share with others in their contacts.
   • For such an application, you would automatically sort the frameworks by the mobile app, then any middleware or a mobile-backend.
   • If you write your own backend and business logic, then you would add that as well.
2. A web application that allows users to track their monthly grocery expenses.
   • The framework by default gets priority; .NET, Spring, or some other web application development framework.
   • Even though you do build an interface for the customers to use, you put it secondary, because your business is around the API and not the way that this list is communicated to the customers.
3. A B2B API gateway that allows one company to manage fulfillment services for another company.
   • You would put multiple frameworks as a priority and a must have.
   • You would avoid onboarding an engineering that does not have the big picture in their mind.

Imagine these three organizations; technically, they all have a backend, a “frontend” and a data storage. The infrastructure would have firewalls for security, load balancers for optimization, and what not. But, it doesn’t take away the fact that each of these services has a server that processes the business logic, an interface for the customers and clients to access the services, and a central storage where everything is kept for the time it is needed to be kept.

Tech Stack Communication

Nobody writes IIS, or Apache, or other server components in their tech stack. Why? Is there not a “production-ready” server that must be communicated to the customers? I can understand hiding the version-specific information in some cases to prevent bad actors from misusing, but it’s well known that most Microsoft-based web applications are hosted on IIS and others on Apache (PHP, Java, etc.). So why is it that the most crucial piece is left out?

The important point to remember and consider is that it is not the Apache server that the engineers and developers are going to program and write the business logic on. It is infact the underlying server-side code framework that they will need to program. ASP.NET, Spring, Express (or even Node.js in some cases) is the actual layer that your developers will most concern with. That is why, it is important that you have someone who is an expert in ASP.NET or Spring, and not someone who is great at IIS or Apache Tomcat.

The top reason that comes to mind for the tech stack communication is:

• To make it easier and simpler for the next engineers to onboard and expect the tech culture of a project or a team.
  • It is entirely true and possible that two teams in the same organization have different cadence for release, a different culture for git-blame, a special way of writing and accepting the changes.
• To make it clear and reasonable why certain development tooling choices were made and how they contribute to the overall ecosystem of the technical products.

When you share the tech stack, you are also exposing your own preferences as to what you believe is important and what is less important. When you say that your application uses:

• Flutter, TypeScript, Firebase, Git

You are explicitly making it clear to any reader that you are not going to compromise on Flutter for app development, TypeScript for backend development, Firebase for mobile-backend (database, authentication, analytics, etc.) and Git as a version control system. For everything else you are open. For example, in a mobile application we would need to use a state management system. In Flutter, we can use either the native state management support or use provider and other complex state management systems. Flutter does not force us, and by keeping this hidden, you are indicating that this is up for a debate. If someone has a better idea and approach to managing state across application UIs, then that’s up for a discussion.

Now that picture starts to look a little focused and communicated.

Each colored section represents a focus point in terms of tech stack. You are able to put blue and green blocks because the red block supports that. And the pink block is supported by the blue block and so on and so forth. In order to swap the pink block, you would need to ensure the jigsaw puzzle is solved between the blue block and the next colored block (orange, for example). And that would also have an impact on the blocks above and so on.

AI-Driven Tech Stacks

All of sudden, as vibe coding platforms emerge, we see a plethora of SaaS and job opportunities all listing these frameworks at the center, right, and left. We see the mention of Replit, Codex, Lovable, etc. as the primary tech stack and then other languages and frameworks emerge. The main reason behind this is that now the primary investment was made to support the development around these vibe platforms.

Is “vibing” a framework, a platform, or something else?

Now, the whole scenario of a project being built with .NET framework, or Next, or MEAN stack app is that you want to communicate the most important aspects of a project. In a .NET application, the most important component is definitely the .NET stack, and you need to have the audience understand that they need to be hands-on with .NET framework and understand different dependencies, lifecycle events, and more. For a MEAN app, you need the developer to be hands on with all–database, UI, and the backend API layer.

With that, I believe the reason the “vibe platform” is communicated is to define strict expectations that the platform is primarily developed using the “vibe platform” and you must have the skills and basic understanding of getting the “vibe platform” to work.

The point is, an application is not just the framework that is being used to write the business-logic, but it contains layers over layers of services and runtimes that make it function. But, those layers and services can be replaced. An IIS web server can be easily replaced with an Apache alternative, or a Redis cache can be swapped for a memcached or an alternative; the swaps would definitely be challenging in their own sense.

When I was working on Distant Ride Fail, I explicitly told him that I would be using Unity and, with this alone, he was informed that the project would use C# as a language, and everything that comes with it.

Conclusion

I believe, the addition of a vibe platform demands that we consider it one of the most important frameworks (if not “the ultimate” most important framework). If you develop your applications using vibe platforms then it makes sense and is only fair that you communicate this to the onboarding engineers and developers.

I have seen several posts and opportunities on LinkedIn or freelance platforms such as Upwork where the founders clear communicate that they expect some skills with AI-driven or vibe platforms. And that is a great thing–even though I am personally not a viber. And that gives me an idea that I must avoid these projects as “thar be dragons”.