Forem: Hadil Ben Abdallah

30 Web Development Tips from a Mid-Level Developer

Hadil Ben Abdallah — Tue, 14 Apr 2026 13:00:43 +0000

For a long time, I thought becoming a “better developer” meant learning more tools.

More frameworks.
More libraries.
More tutorials.

If I wasn’t constantly upgrading my stack, I felt like I was falling behind.

So I kept switching.
Trying new things.
Starting… but rarely going deeper.

And somehow… I wasn’t really improving.

It took me a while to realize this simple truth:

Growth doesn’t come from doing more things…
It comes from understanding the right things better.

1. Master the fundamentals

You can’t skip HTML, CSS, and JavaScript and expect frameworks to carry you.

If your basics are weak:

You will struggle with React patterns
You will misunderstand Next.js behavior
You will constantly feel like you’re guessing

Strong fundamentals remove most of the confusion you feel later.

2. Understand what the browser is doing

A lot of developers start with frameworks before they understand the environment.

But everything still runs in the browser.

Requests, rendering, caching, DOM updates… it’s all happening underneath your code.

If you don’t understand this layer, frameworks feel like magic instead of tools.

3. Improve your Data Structures & Algorithms thinking

Even if you’re not doing LeetCode every day, you still need structured thinking.

You don’t need to memorize everything, but you should understand patterns like:

Searching and sorting
Recursion and iteration
Stacks, queues, hash maps

This kind of thinking shows up everywhere, not just in interviews.

It’s the difference between writing working code and writing scalable code.

4. Understand frameworks instead of memorizing them

Frameworks aren’t magic.

Learn what they actually do:

Rendering models
Routing
State management
Server vs client behavior

Once you understand the “why”, the “how” becomes easier.

5. Context matters more than advice

A lot of dev advice online is correct… but only in the right context.

What works in a side project might fail in production.
What works in a startup might break in enterprise systems.

Instead of asking “Is this good?”
Ask: “When is this good?”

6. Understand the bigger picture

Don’t just implement tickets.

Understand:

What problem they solve
Who they impact
Why it matters now

That’s what separates developers from engineers.

7. TypeScript is not about typing

Most people think TypeScript is just about adding types.

It’s not.

It’s about:

Making intent clear
Catching mistakes early
Making refactoring safer

Once you get used to it, plain JavaScript starts to feel risky.

8. Next.js is not just “React but easier”

If you use Next.js, go deeper than the folder structure.

Understand:

Server vs client components
SSR vs CSR trade-offs
Caching behavior
Routing model

Otherwise, your app will work… but behave unpredictably in production.

9. Learn your tools properly

A surprising amount of time is lost because of poor tool usage.

Master:

Git
Your IDE
The browser dev tools

These tools are used every day.

Small improvements here compound faster than you expect.

10. Break problems into smaller pieces

Big tasks feel overwhelming.

But most of them are just a collection of small problems combined.

Once you split them into:

UI
logic
API
State
Edge cases

the task becomes much easier to handle.

You also start seeing progress faster.

Solve one piece at a time, and things start moving.

11. Don’t copy code you can’t explain

Copying code is fine when you understand what it does.

The problem starts when you copy blindly.

Later, when something breaks:

You won’t know where to look
You won’t know what changed
You won’t know what assumptions you made

That’s how small bugs turn into long debugging sessions.

12. Prefer readable code over clever code

Clever code feels good when you write it.

But later, it becomes harder to read, debug, and modify.

Most code is read more than it is written, so readability always wins in the long run.

Clever code impresses once. Readable code helps forever.

13. Don’t optimize too early

A common mistake is trying to optimize before you fully understand the problem.

First make it work.

Then make it clean.

Then optimize only if it actually matters.

Premature optimization adds complexity without value.

14. Read your own code like a stranger

Come back to your code after a few days.

If it confuses you… that’s feedback.

Clear code should explain itself without effort.

15. Googling is a real skill

You don’t need to remember everything.

The skill is not memorization; it’s navigation.

You need to know:

How to search
How to filter noise
How to recognize good answers

That’s what experience actually looks like.

16. Debugging = removing wrong assumptions

Most bugs aren’t complicated.

They’re just lies you told yourself without realizing it.

“This value is always defined.”
“This state updates immediately.”
“This API always returns what I expect.”

Debugging is just proving yourself wrong until reality is left.

17. Build more than you consume

It’s easy to feel productive watching tutorials because everything makes sense while watching.

But real understanding only happens when you’re alone in front of a blank screen trying to build something.

If you never leave tutorials, you never learn how to think.

So close the video.
Try things yourself.
Get stuck.

That’s where growth happens.

18. Take breaks when you’re stuck

Forcing your way through a problem feels productive.

But stepping away often solves it faster.

Your brain keeps working even when you stop staring at it.

19. Ask for help before you’re stuck for too long

Staying stuck for hours rarely leads to a breakthrough.

It usually leads to frustration.

Most developers are fine helping, but only if you’ve already tried to solve the problem yourself first.

20. Ask better questions

Nobody can help a vague “it’s not working”.

But they can help this:

Here’s what I tried
Here’s what I expected
Here’s what actually happened

Good questions don’t just get answers faster.
They also force you to understand the problem better.

21. Communication is part of the job

Writing code is only one part of being a developer.

The other part is:

Explaining decisions
Discussing trade-offs
Aligning with teammates

In real teams, communication problems cause more issues than technical ones.

22. Learn to explain your thinking clearly

Writing code is only half the job. Explaining it is the other half.

You need to be able to describe what you’re doing, why you’re doing it, and what tradeoffs exist.

This shows up in:

Code reviews
Documentation
Daily team conversations

Clear communication prevents misunderstandings that would otherwise turn into bugs or wasted time.

If you can make complex ideas simple for others, you instantly become more valuable in any team.

23. Done is better than perfect

Trying to make things perfect before shipping usually slows everything down.

You learn much more from a working version in production than a perfect version sitting locally.

24. Always think about user experience

Even if you’re not a designer, you still shape the experience.

Loading states
Feedback
Responsiveness

These details matter more than most developers think.

Because users don’t see your code.

They feel it.

25. Show enthusiasm for the work

Skill alone isn’t enough if you look disconnected from what you’re building.

People notice when you actually care about the product, not just the code.

You don’t need to be overly excited, but you do need to show interest in solving problems, not just finishing tasks.

That attitude makes you more reliable, more trusted, and more likely to get better opportunities.

Most of the time, enthusiasm quietly compounds into career growth.

26. Find mentors

You don’t need to figure everything out alone.

A good mentor can save you months of trial and error by pointing out what actually matters.

They don’t give you answers for everything, but they help you avoid stupid detours.

Sometimes it’s a senior dev at work, sometimes it’s someone online whose work you respect.

Learn from people who are already where you want to be.

27. Contribute to open-source

Open-source teaches you things tutorials never will.

You deal with real codebases, real constraints, and real people reviewing your work.

At first, it feels intimidating, but that’s exactly the point.

Start small:

Fix bugs
Improve docs
Submit tiny PRs

Over time, you learn how large systems are actually structured and how collaboration really works outside your own bubble.

28. Stay open to learning new things

The moment you think you’ve “figured it out”, you start slowing down.

Tools change, patterns evolve, and what worked last year might not be enough today.

You don’t need to chase every trend, but you should stay flexible.

Be willing to question your own habits and try better approaches when they show up.

29. Mentor younger devs

Teaching is one of the fastest ways to level up your own understanding.

When you explain concepts to someone else, you immediately see the gaps in your knowledge.

You don’t need to be an expert to help; just a bit ahead is enough.

Answer questions
Review code
Guide someone through their first projects

It forces you to think more clearly, and it makes the whole ecosystem better at the same time.

30. Share your work over social media

A lot of good work stays invisible simply because nobody talks about it.

Posting your projects, lessons learned, or small wins helps you build a reputation over time.

You don’t need to “go viral”, you just need consistency.

People start recognizing your name, and opportunities often come from that quiet visibility.

Final Thoughts (From One Developer to Another)

Most growth doesn’t come from big breakthroughs.

It comes from small improvements… repeated consistently.

You don’t need to know everything.
You just need to care a little more each time you build.

That’s how average code becomes solid.
And solid developers become great ones 💻

Wishing you consistency, clarity, and real growth in your journey, friends 💙.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

Data Engineering Interview Prep (2026): What Actually Matters (SQL, Pipelines, System Design)

Hadil Ben Abdallah — Thu, 09 Apr 2026 14:55:50 +0000

Most candidates don’t fail data engineering interviews because of SQL or Python; they fail because they can’t connect everything together under pressure.

If you’ve ever prepared for a data engineering interview, you already know this:

It’s not just “study SQL and you’re good.”

It’s SQL… plus Python… plus system design… plus data modeling… plus explaining your past projects like a storyteller. And somehow, you’re expected to bring all of that together under pressure, in a limited amount of time, while thinking clearly out loud.

And the hardest part?

You don’t always know what matters most, so you end up preparing everything… and still feeling unprepared.

I’ve seen people spend weeks grinding random problems, jumping between resources, and consuming endless content… only to get rejected because they couldn’t design a simple data pipeline or explain their decisions clearly.

So let’s fix that.

This guide is not a list of everything you could study.
It’s a focused breakdown of what actually moves the needle in real data engineering interviews: the things that consistently show up, and the skills that genuinely make a difference.

What Do Data Engineering Interviews Test in 2026?

If you're wondering how to prepare for data engineer interview questions, it starts with understanding what companies are really evaluating.

At a high level, most interviews are trying to answer one simple question:

“Can this person work with real data systems?”

That question translates into multiple layers. It’s not just about writing correct code, but about how you approach messy, ambiguous problems and turn them into structured solutions.

You’re expected to:

Write SQL that solves real business questions, not just textbook queries
Manipulate and process data using a programming language
Design pipelines that make sense in real-world scenarios
Understand how data is structured, stored, and accessed
Communicate your thinking clearly, even when you’re unsure

Here’s the reality most people miss:

Data engineering interviews are less about memorization and more about how you think through imperfect, real-world data problems.

Interviewers are paying attention to your reasoning just as much as your answers.

Core Data Engineering Interview Skills You Must Master

If you focus consistently on the right areas, you don’t need to chase every possible topic.

A strong foundation in a few key domains already puts you ahead of most candidates.

To prepare for a data engineering interview in 2026, focus on:

SQL for real business problems (joins, window functions, CTEs)
Python for data transformation and edge cases
Data modeling (facts, dimensions, trade-offs)
ETL pipelines (batch vs streaming, reliability)
Data-focused system design (data flow and scalability)
Presenting your data engineering projects (impact, decisions, trade-offs)

Here’s a simple way to visualize how these skills connect together in real interviews:

Data engineering interview skills roadmap

You don’t need to master everything at once, and you don’t need perfect knowledge in every area. But you do need enough depth to connect these pieces together in a coherent way when solving problems.

1. SQL Interview Questions for Data Engineering (What to Expect)

If there’s one skill that can carry you through multiple interview rounds, it’s SQL.

But not basic queries.

You need to be comfortable with:

Window functions like ROW_NUMBER, RANK, and LAG
Complex joins across multiple tables
Common table expressions (CTEs)
Aggregations that handle edge cases and real constraints

Most interview questions are not framed as “write a query.”

They’re framed as:

“Here’s a dataset and a business problem. Now figure it out.”

That means your job is not just writing SQL syntax, but translating a problem into logical steps before even touching the query.

A small mindset shift helps a lot here:

Instead of asking, “What query should I write?”
Start asking, “What is happening in this data, and what do I need to extract from it?”

That’s the level interviewers are evaluating.

For example, a common data engineering interview question is:
“Find the top 3 most active users per day.”

This requires combining window functions, grouping, and careful handling of edge cases.

When I first tried writing SQL queries under interview pressure, I realized my solution worked, but explaining why it worked clearly was even harder.

2. Python for Data Engineering Interviews

You don’t need to be a competitive programmer or solve extremely complex algorithmic problems.

But you do need to be comfortable working with data programmatically.

That includes:

Transforming and manipulating data structures (lists, dictionaries, dataframes)
Writing clear, readable logic that others can understand
Handling edge cases without breaking your solution

In many interviews, Python is used to simulate real-world data processing tasks rather than abstract algorithm challenges. You might be asked to clean data, restructure it, or process it step by step.

So instead of thinking in terms of “DSA difficulty,” think in terms of:

Can you take raw data and turn it into something usable, efficiently and clearly?

3. Data Modeling Interview Questions and Tips

This is one of the most underrated yet critical parts of data engineering interviews.

You might be given a scenario like:

“Design a data model for a ride-sharing platform”

“How would you structure analytics for an e-commerce system?”

What interviewers are really testing is your ability to think structurally:

Can you identify the key entities in a system?
Can you separate facts from dimensions?
Can you design something that supports real analysis?
Do you understand trade-offs between simplicity and performance?

Many candidates skip this area because it feels abstract at first. But in practice, it’s one of the clearest signals of whether someone understands how data systems actually work.

If you ignore this, you’re leaving a major gap in your preparation.

4. ETL and Data Pipeline Interview Questions (Real Scenarios)

This is the core of what data engineers actually do.

One thing I noticed while practicing pipeline design is that it’s easy to overcomplicate solutions.

In interviews, simpler and well-explained designs often perform better than complex ones that are hard to justify.

You should be comfortable explaining how data moves through a system, from ingestion to transformation to storage, and why each step exists.

That includes understanding:

The difference between batch and streaming processing
How tools like Airflow or Spark fit into a pipeline
How to design systems that are reliable and scalable
Where things can break and how to handle failures

A helpful way to think about this is:

“If I had to build this system from scratch, how would I design it and why?”

Even if your answer isn’t perfect, showing structured thinking and clear reasoning makes a big difference.

5. Data Engineering System Design Interview Questions

This is not traditional backend system design.

In data engineering interviews, system design focuses more on data flow, scale, and architecture.

You might be asked to:

Design a real-time analytics pipeline
Handle large volumes of incoming data
Choose between different storage solutions

The goal is not to produce a perfect architecture diagram.

The goal is to demonstrate:

Clear, step-by-step thinking
Awareness of trade-offs
Ability to explain decisions logically

Interviewers are not expecting perfection. They’re looking for structured reasoning and the ability to adapt when new constraints are introduced.

6. Presenting Your Data Engineering Projects in Interviews

This is where you can stand out immediately if you do it right.

Most candidates describe their projects by listing tools:

“I used Spark, AWS, and built a pipeline.”

That doesn’t tell much.

A stronger way to present your projects is to focus on:

The problem you were solving
Why it mattered
The decisions you made and their trade-offs
The impact of your solution

Interviews are not just technical evaluations. They are also storytelling exercises. The way you explain your work can be just as important as the work itself.

How to Practice for Data Engineering Interviews Efficiently (Without Wasting Time)

This is where many people lose momentum.

They either jump randomly between topics without a clear direction, or they over-focus on one area, usually coding, while neglecting everything else.

A more effective approach is to build consistency and context into your practice:

Practice SQL regularly, not in bursts
Combine coding with real-world scenarios instead of isolated problems
Simulate interview conditions where you explain your thinking

One thing that helps a lot, and is often overlooked, is practicing in an environment that feels close to actual interviews.

Platforms like datadriven.io are one example, but the key idea is to move away from isolated problems and toward scenarios that reflect real interview situations.

Instead of solving disconnected problems, you’re working through structured scenarios that reflect how data problems appear in real interviews.

You’re not just writing queries; you’re thinking about context, trade-offs, and decisions.

Another underrated advantage is being able to practice problems based on specific companies. Instead of preparing in a vacuum, you can focus on the types of questions that companies actually ask, which helps you align your preparation with real interview patterns rather than guessing what might come up.

What makes a difference is that, in DataDriven, you can:

Practice SQL and Python in realistic situations, not artificial ones
Work through data modeling and pipeline-related problems
Simulate interview-style thinking rather than just “getting the answer”
Engage with a community of learners discussing similar challenges
Stay consistent with features like daily problems that keep you in a steady learning loop

That combination of structured practice, realistic context, and consistency is what most candidates are missing when they rely only on random resources.

The Mindset That Will Help You Succeed in Data Engineering Interviews

Here’s something most guides don’t emphasize enough:

You don’t fail interviews because you don’t know enough.

You fail because:

You panic under pressure
You rush to answer instead of thinking
You don’t structure your thoughts clearly

The candidates who perform well usually do one thing differently.

They slow down.

They take a moment, break the problem into parts, and think out loud. Even if their final answer isn’t perfect, their reasoning is clear and easy to follow.

That clarity builds trust with the interviewer.

And in many cases, that matters more than getting everything right.

Final Thoughts

If you’ve been jumping between SQL, Python, and system design without a clear strategy, you’re not alone, and fixing that gap is what makes the biggest difference.

Preparing for data engineering interviews can feel overwhelming because there’s always more to learn and more tools to explore.

But if you focus on the fundamentals, SQL, data modeling, pipelines, and clear thinking, you’re already building the right foundation.

And more importantly, you’re preparing for the actual job, not just the interview.

If you’re preparing for a data engineering interview in 2026, what’s been the hardest part for you so far, SQL, pipelines, or system design?

💬 Drop a comment; I’d love to hear how others are approaching it and where people are getting stuck.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

Final Round AI vs Interview Coder: Best AI Tool for Coding Interview Prep (2026)

Hadil Ben Abdallah — Mon, 06 Apr 2026 06:53:10 +0000

Most developers don’t fail interviews because they lack knowledge; they fail because they can’t communicate it under pressure.

This is a common problem in technical interviews, especially during coding interview prep where knowing the solution isn’t the same as explaining it clearly.

You’ve solved enough problems. You’ve reviewed patterns. You know how things work. And yet, in the actual interview, something feels off. Your explanation gets messy, you lose your train of thought, and suddenly a problem you’ve solved before feels unfamiliar.

That gap is exactly why AI interview tools like Final Round AI and Interview Coder are becoming popular in coding interview prep.

I didn’t look at them as “features to compare" but as tools trying to solve a very specific problem: helping developers translate knowledge into performance. And once you look at them that way, the difference between them becomes much clearer.

Why AI Interview Tools Are Getting So Much Attention

Coding interview prep has always been heavily skewed toward knowledge.

We spend hours solving problems, memorizing patterns, and reviewing system design concepts. That part is necessary, but it’s only half the equation. Interviews are interactive, and that interaction is where most candidates struggle.

It’s not just about getting to the right answer; it’s about how you get there, how you explain your decisions, and how you react when things don’t go as planned.

That’s the gap AI interview tools are trying to fill in modern technical interviews. But depending on how they approach it, they either improve your thinking… or just polish your answers.

What Is Final Round AI?

Final Round AI is an AI interview tool designed for coding interview prep, built around the idea that interview performance is a skill on its own.

Instead of treating interviews like a list of questions to practice, it focuses on how you structure your thoughts while speaking. You’re constantly pushed to explain your reasoning, stay organized, and avoid the kind of scattered thinking that usually shows up when you’re under pressure.

What stands out is that it doesn’t try to make things easier. It tries to make them realistic. You’re practicing in a way that forces you to deal with the same friction you’d face in an actual interview.

This kind of mock interview practice is especially useful for improving performance in real technical interviews.

Over time, that shifts your mindset. You stop chasing perfect answers and start focusing on delivering clear, structured explanations.

Explore Final Round AI

What Is Interview Coder?

Interview Coder is an AI interview tool more aligned with traditional coding interview prep.

It helps you build and refine answers to common technical interview questions by giving suggestions, guiding your responses, and exposing you to common interview questions. It’s practical, easy to use, and especially helpful if you’re still figuring out how to approach certain problems.

The environment feels safe and controlled, making it a good option for low-pressure mock interview practice.

That’s useful, but it also means you’re not really training the part of interviews that tends to break people: thinking clearly while someone is actively evaluating you.

Explore Interview Coder

Final Round AI vs Interview Coder: A Deep Comparison

At a glance, both tools seem to help with interview prep. In practice, they focus on completely different aspects of it.

1. How Close It Feels to a Real Interview

The biggest difference in coding interview prep shows up in how each tool simulates real technical interviews.

Final Round AI creates an environment where you have to respond in real time, organize your thoughts as you speak, and maintain clarity without pausing to rethink everything. That constant pressure is intentional, because it mirrors what actually happens in interviews.

Interview Coder feels more like a guided workspace. You can take your time, rethink your answers, and gradually improve them. It’s a smoother experience, but also one step removed from the reality of live interviews.

If your goal is to reduce surprises on interview day, realism matters more than comfort.

2. Practicing Thinking vs Practicing Answers

Key difference: thinking vs answering

Final Round AI trains the process of thinking out loud. You’re not just solving the problem; you’re learning how to communicate your reasoning as it unfolds. That’s a skill most developers don’t consciously practice, but it’s exactly what interviewers pay attention to.

Interview Coder focuses on the outcome. It helps you shape better answers, refine your explanations, and understand what a strong response looks like.

One improves how you think in the moment. The other improves what you say after thinking about it.

3. The Type of Feedback You Get

Feedback is where many AI interview tools sound useful but don’t actually improve technical interview performance.

Final Round AI leans into communication-focused feedback. It highlights where your explanation loses clarity, where your structure breaks down, and where you skip important steps in your reasoning. It’s less about correctness and more about how your answer is experienced by someone listening.

Interview Coder’s feedback is more content-driven. It helps you make your answers more complete, more polished, and more aligned with expected solutions.

Both are helpful, but they improve different layers of your performance.

4. The Overall Experience

In coding interview prep, how an AI interview tool feels to use affects how consistently you’ll practice.

Final Round AI is more immersive. It demands attention and puts you in situations that feel close to real interviews. That intensity can be challenging, but it’s also what makes it effective.

Interview Coder is lighter and more flexible. You can jump in, practice a few questions, and leave with something useful. It’s easier to integrate into a routine, especially if you’re balancing prep with other commitments.

So it really comes down to whether you want something that pushes you or something that supports you.

Summary Comparison: Final Round AI vs Interview Coder

Here’s a quick comparison of both AI interview tools for coding interview prep:

Aspect	Final Round AI	Interview Coder
Interview simulation	High, close to real scenarios	Moderate, more controlled
Thinking in real time	Core focus	Limited
Feedback type	Communication and clarity focused	Answer and content focused
Learning style	Immersive and performance-driven	Guided and preparation-focused
Best use case	Interview readiness	Answer refinement

Both tools support technical interviews, but they focus on different parts of the coding interview prep process.

Who Each Tool Is Best For

In coding interview prep, choosing the right AI interview tool depends on whether you’re trying to improve your understanding of technical interview questions or your ability to perform under real interview pressure.

Interview Coder is a good fit if you:

Are still building your understanding of common interview questions
Want structured guidance on how to answer effectively
Prefer a calmer, low-pressure way to improve

Final Round AI makes more sense if you:

Want to simulate real interview conditions as closely as possible
Need to improve how you explain your thinking in real time
Tend to lose clarity or structure when under pressure
Want to practice staying composed while solving problems live
Care about how your answers sound, not just what they contain
Are preparing for interviews where communication is heavily evaluated

Why Final Round AI Feels Different

After testing both in a coding interview prep, the distinction becomes pretty straightforward.

Interview Coder helps you build better answers in a controlled environment.

Final Round AI focuses on what happens when control is gone which is exactly what happens in real technical interviews and you’re expected to perform.

That difference might not seem huge at first, but it becomes very obvious the moment you step into a real interview.

Because interviews don’t test how well you’ve prepared in isolation. They test how well you can communicate that preparation under pressure.

The Developer Takeaway

If you’ve ever finished an interview and thought:

“I could’ve explained that way better”
“I lost my structure halfway through”
“I knew it… I just didn’t show it properly”

then you’re not dealing with a knowledge problem.

You’re dealing with a performance gap.

That’s exactly where Final Round AI stands out. It doesn’t try to give you cleaner answers to memorize. It forces you to deal with how you think, how you speak, and how you hold it together when things get uncomfortable.

And that’s the part most prep completely ignores.

Final Thoughts

AI interview tools are slowly reshaping coding interview prep, but it’s also exposing something that was always there.

There’s a difference between understanding a problem and communicating your understanding.

Some tools help you close the first gap.

Others help you close the second.

And when you’re sitting in front of an interviewer in a real technical interview, the second one is usually the one that decides how things go.

💬 Have you tried either of these tools? Or do you rely on platforms like LeetCode or mock interviews? I’m curious what actually worked for you.

Thanks for reading! 🙏🏻 Please follow Hadil Ben Abdallah & Final Round AI for more 🧡

Final Round AI Follow

Final Round AI helps you get ready for your next interview with tools like AI Interview Copilot, AI Mock Interviews, top interview questions, AI Resume Builder, Auto Apply and more to make sure you’re fully prepared.

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

Do You Actually Need an AI Gateway? (And When a Simple LLM Wrapper Isn’t Enough)

Hadil Ben Abdallah — Fri, 03 Apr 2026 06:36:39 +0000

It always starts the same way.

You add a single LLM call to your app. Maybe it’s OpenAI, maybe Anthropic. You test it, it works, and within a few hours you’ve shipped something that actually feels powerful. For a moment, it feels like the easiest integration you’ve ever done.

And honestly, at that stage, it is.

The problem is that this setup doesn’t stay simple for long.

Another team hears about it and wants access. Then product asks if you can switch models for better results. Finance wants to know how much this is costing… and suddenly no one has a clear answer.

Then security joins the conversation and asks the uncomfortable question:
“Where exactly is our data going?”

That’s usually when things stop feeling clean.

API keys are scattered across services. Switching models requires code changes. Costs are vague. And when something breaks, there’s no single place to look.

At this point, most engineers quietly start Googling:

“Do I actually need an AI Gateway?”

What an AI Gateway Actually Is (Without Overcomplicating It)

An AI Gateway isn’t an abstract concept. It’s a practical layer that sits between your application and the model providers you’re calling.

Instead of your app talking directly to OpenAI or Anthropic, every request goes through the gateway. That’s where control and visibility start to live.

How an AI Gateway sits between your application and model providers, adding control, visibility, and governance

It handles things you didn’t need on day one but eventually can’t avoid: routing requests between models, enforcing rate limits, tracking costs, applying guardrails, and giving you a clear view of what’s happening across your system.

Most teams don’t start here. They begin with a direct SDK call, which is completely reasonable. Sometimes they add a lightweight proxy later to simplify model switching. That works for a while, especially if your scope is small.

But there’s a real difference between something that helps you call models and something that helps you manage them.

You don’t feel that difference early on. You feel it when things start scaling: more teams, more models, more constraints, and more questions about costs, reliability, and compliance.

AI Gateway vs API Gateway (Why This Confuses So Many People)

At first glance, it’s easy to assume an API Gateway already solves this problem. After all, API gateways handle routing, authentication, and rate limiting for traditional services.

So why isn’t that enough?

The answer comes down to what each system actually understands.

An API Gateway treats requests as generic traffic. It doesn’t know what a token is. It doesn’t understand prompts. It has no awareness of how model usage translates into cost, latency, or risk.

An AI Gateway operates at a different level.

API Gateway vs AI Gateway — the difference between routing requests and actually understanding them

It understands that a request isn’t just a request; it’s a prompt with tokens, a response with potential risks, and a cost attached to every interaction. That allows it to track usage in a way that reflects reality.

The difference becomes obvious very quickly in practice.

For example:

An API Gateway can tell you, “Team A made 10,000 requests.”
An AI Gateway can tell you, “Team A sent 4.2M tokens to GPT-4o at a cost of $84, with an average latency of 340ms, and 3 requests triggered the PII guardrail.”

That’s the shift from simple routing to actual understanding, and it’s exactly what starts to matter once usage grows beyond a single team.

So… Do You Actually Need One?

Here’s the honest answer: not everyone does.

You probably don’t need an AI Gateway (yet) if:

One team is using one model
Your use case is simple and stable
You don’t have compliance or data residency requirements
Your spend is small and easy to track

In that setup, adding more infrastructure would just slow you down.

You definitely need one if:

Multiple teams are using LLMs independently
You’re using more than one model provider
You have compliance requirements (SOC 2, GDPR, HIPAA, etc.)
You can’t answer: “What did we spend on AI last month by team?”
You’ve had (or fear) data leaks through LLM APIs

At that point, the problem isn’t calling models. It’s managing them.

There’s also a subtle signal that often gets missed: if switching models requires code changes, or if each team is solving the same integration problems in slightly different ways, you’re already accumulating hidden complexity. It just hasn’t fully surfaced yet.

What a Production AI Gateway Actually Looks Like

Once you move into production, the role of an AI Gateway becomes much clearer.

Instead of every team managing its own API keys and configurations, you introduce a single unified layer that everything goes through. That alone removes a surprising amount of hidden complexity.

It also changes how teams interact with models. Rather than dealing directly with providers, teams work through a consistent interface where access control, budgets, and rate limits are defined centrally. This gives you governance without slowing down development.

Reliability improves too. In a basic setup, if a provider goes down, your application goes down with it. With a gateway in place, requests can be automatically routed to another provider without code changes. That resilience becomes critical as usage grows.

Visibility is where the shift becomes dramatic.

Example of real-time observability in an AI Gateway — tracking costs, requests, errors, and guardrail activity across LLM workloads (source: TrueFoundry platform)

A production-grade gateway lets you trace every interaction, from the initial prompt to the final response, along with latency, cost, and any policy violations. Debugging, auditing, and optimization stop being guesswork.

Security and compliance also stop being an afterthought.

Example of fine-grained data access control and governance in an AI Gateway — managing team-level permissions and trace visibility (source: TrueFoundry platform)

You can apply guardrails on inputs and outputs, filter sensitive data, detect prompt injection patterns, and enforce policies consistently across teams. And because the gateway runs inside your own infrastructure, you stay in control of where your data goes.

For example, platforms like TrueFoundry implement this as a unified control plane:

One API key across all model providers
Built-in cost tracking and per-team governance
Model fallback and intelligent routing
Full request-level tracing and observability
Guardrails for both prompts and responses
Deployment in your own environment (VPC, on-prem, or multi-cloud)

Example of a unified AI Gateway architecture, adapted from the TrueFoundry website

TrueFoundry is recognized in the 2026 Gartner® Market Guide for AI Gateways and handles production-scale workloads, processing 10B+ requests per month while maintaining 350+ RPS on a single vCPU with sub-3ms latency. It’s compliant with SOC 2, HIPAA, GDPR, ITAR, and the EU AI Act and is trusted by enterprises including Siemens Healthineers, NVIDIA, Resmed, and Automation Anywhere.

The Trade-Off Most Teams Realize Too Late

Introducing an AI Gateway comes with overhead. You are adding a new layer to your architecture, which requires setup and maintenance.

But here’s what most teams underestimate: without a gateway, complexity doesn’t disappear; it spreads.

It spreads across services, teams, and slightly different implementations of the same logic. What starts as a simple integration turns into fragmented code, inconsistent policies, duplicated effort, and limited visibility.

Over time, managing this scattered complexity ends up costing more in debugging, outage handling, and cost tracking than implementing a proper AI Gateway in the first place.

Where’s the Actual Line?

The shift usually happens when AI usage stops being just a feature and starts becoming infrastructure.

Multiple teams, multiple models, and real-world constraints like compliance, cost tracking, and reliability change the problem. You’re no longer just integrating an API; you’re managing a system.

That’s where an AI Gateway starts to make sense. Not because it’s trendy, but because it solves a class of problems that only appear at scale.

Recognizing that moment is the real skill. When you’re approaching that threshold, a unified gateway like TrueFoundry is designed to handle it efficiently, reducing hidden complexity without slowing teams down.

Final Thoughts

A simple LLM wrapper is one of the fastest ways to get started with AI, and for a while, it’s exactly what you need.

But as your system grows, what once felt simple can quietly become a limitation. The real challenge shifts from just calling a model to managing everything around it: cost, reliability, compliance, and scale.

If you notice teams duplicating integrations, struggling with visibility, or juggling multiple providers, that’s your signal; it’s time to level up your AI infrastructure.

You can try TrueFoundry free, no credit card required, and deploy it in your own cloud in under 10 minutes. See how a unified AI Gateway brings control, observability, and resilience to your workflows without slowing you down.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

How a Payment Problem Unexpectedly Changed My Career Path in Tech

Hadil Ben Abdallah — Tue, 31 Mar 2026 06:35:40 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

Sometimes the biggest turning points in a career don’t come from success.
They come from the problems you didn’t expect to face.

When I first started learning web development, the thing that fascinated me most wasn’t just the code itself.

It was the transformation.

You start with a blank page on localhost. Nothing exists yet. No layout, no colors, no interactions. Just an empty canvas.

Then slowly things begin to appear.

A navigation bar.
A section layout.
A carefully chosen color palette.

Buttons start responding. Animations begin to move. Eventually the page that once looked empty becomes a real website that someone might actually use.

That process never stopped feeling magical to me.

Because of that, I imagined a very clear path for my career.

I wanted to become a freelance web developer working with international clients from home. At this stage of my life, staying close to my family is important, so remote freelance work felt like the perfect balance.

So I prepared for that path.

I built projects.
I improved my skills.
I started reaching out to potential clients.

Eventually, conversations began happening. Some people liked my work, and collaborations started to look possible.

But then an unexpected problem kept appearing at the worst possible moment.

The payment discussion.

The Problem I Never Expected

Most international clients prefer paying through PayPal.

Normally, that wouldn’t be a problem.

Except PayPal doesn’t work in my country right now.

So the conversation often went like this:

Client: “We usually pay via PayPal.”
Me: “Unfortunately PayPal isn't available in my country.”

And suddenly the conversation became complicated.

Many clients preferred not to deal with alternative payment methods. Over time, I realized that more than 90% of potential clients relied on PayPal, and that single limitation was enough to block many collaborations before they even started.

It was frustrating, because the problem had nothing to do with my skills or the quality of my work.

It was purely logistical.

When Bank Transfers Became Another Obstacle

At first, I thought bank transfers could solve the problem.

Some clients were open to the idea, which gave me hope.

But when I asked my bank about receiving international transfers, the explanation wasn’t encouraging.

If the transfer exceeded around $500, the payment could easily get stuck in administrative procedures.

The bank might ask questions like:

Where did this money come from?
Do you have an invoice?
Are you officially registered for this work?
Can you provide documentation for the service?

Even after providing everything, there was still a strong chance the payment might not go through smoothly.

Trying to build a freelance career while constantly worrying about whether you will actually receive the payment is exhausting.

The Partial Solution That Rarely Worked

The only practical workaround I found was Upwork.

The platform allowed me to withdraw earnings in smaller amounts instead of one large transfer, which helped avoid the banking issues triggered by bigger payments.

Technically, it worked.

But in practice, another problem appeared.

Most clients I spoke with had never used Upwork before, and they simply weren’t interested in creating an account, setting up contracts, and managing payments through a platform.

For them, it felt like an unnecessary extra step.

So even when I found a possible solution, it rarely worked in real situations.

After losing several opportunities because of these complications, the frustration started building up.

That period was probably the closest I came to feeling burned out.

For a while, it made me question whether freelance development was even a realistic path for me.

When Writing on DEV Became My Escape

Around that time, I started writing on DEV Community.

Not because I had a strategy.

Not because I was trying to build a career from it.

I simply needed a place to release some of the frustration I was feeling.

Writing about programming, lessons I learned, and my experiences in tech became a small way to clear my mind.

At first it felt like I was just sharing thoughts into the void.

But slowly something surprising happened.

People started reading.

They left comments.
They shared their own experiences.
Sometimes they even thanked me for explaining things clearly.

Some of my articles reached over 20,000 readers, which I never expected.

That’s when I realized something unexpected:

I genuinely enjoy writing.

The Message That Changed Everything

The funny part is that I wasn’t even looking for writing clients.

But one day someone contacted me after reading one of my articles and asked if I would be interested in writing technical content for them.

That moment changed how I saw writing online.

Publishing articles isn’t just about sharing knowledge.

Sometimes it quietly opens doors you didn’t even know existed.

That opportunity became the beginning of my technical writing journey.

And interestingly, that first collaboration also solved a problem that had been blocking many of my earlier freelance opportunities.

The client was open to paying through Upwork.

For the first time, the payment conversation didn’t end the project before it even started.

After that experience, things slowly began to improve.

Over time, I met more clients who were open to flexible payment solutions.

Some were comfortable working through Upwork.

Others were fine sending via direct bank transfers.

Since writing an article will obviously never exceed the $500 threshold that usually triggers complications with my bank 😅, those collaborations became much easier to manage.

Because of that flexibility, I had the chance to work with some wonderful clients and build collaborations that I’m genuinely proud of.

But the reality is that the limitation hasn’t disappeared completely.

Even today, I still lose many opportunities simply because the payment conversation eventually comes back to PayPal 😥.

Still, that first writing opportunity changed something important for me.

Once things started becoming more serious, I realized that writing professionally involves much more than simply explaining technical topics.

I started learning about:

SEO
Content strategy
Article structure
Writing for both readers and search engines

Little by little, writing became more than a hobby.

It became a craft I wanted to improve.

Discovering an Unexpected Creative Side

One of the biggest surprises about technical writing was how creative it actually is.

When I finish writing an article, I don’t only think about the text.

I start looking at the entire experience:

Is the story easy to follow?
Does the structure feel natural?
Are the images placed in the right places?
Do the colors feel pleasant?
Do the call-to-actions appear naturally?

Sometimes I even spend time deciding which emoji fits best in a section 😅

Because a great article isn’t only about information.

It’s also about how enjoyable it is to read.

But My Love for Programming Never Disappeared

Even though writing became a big part of my work, my passion for building things never disappeared.

I still love the process of turning an idea into a real website.

That’s why I also started exploring local clients inside my country.

The budgets and number of projects are obviously different compared to international freelance work, but the satisfaction of building something from scratch is still the same.

Recently, I started working on a website for a Tunisian high school, which is my first full website project with a local client.

And honestly, watching that project slowly come to life feels incredibly rewarding.

The DEV Challenges That Kept Me Building

The DEV community has also been a place where I continue practicing my coding skills.

From time to time, I join coding challenges just for the joy of building something creative.

So far I’ve joined the Frontend Challenge twice.

I didn’t win either of them 😅

But the experience was still incredibly positive.

The encouraging comments, the community support, and even the private messages I received after submitting my projects meant a lot.

In many ways, that encouragement felt just as valuable, if not more, than the prize itself.

If you’re curious, you can check out my submissions for the Halloween Edition challenge and the Office Edition challenge.

I’d genuinely love to hear your thoughts about them; your feedback always means a lot to me.

When Design Became Another Passion

Along the way I also learned Figma.

That completely changed how I approach projects.

Designing the interface before writing the first line of code makes the whole process smoother.

Sometimes I even feel like I enjoy the design phase slightly more than the coding itself.

That interest eventually led me to accept other creative work occasionally, such as:

LinkedIn banners
social media visuals
small visual branding pieces

It’s a different type of work, but it taps into the same creativity that made me fall in love with web development in the first place.

What This Journey Taught Me

When I first imagined my career in tech, I expected a very straightforward path:

Freelance developer → international clients → remote work.

Instead, my journey looked more like this:

Learning web development
Losing clients because of payment limitations
Feeling frustrated and burned out
Starting to write on DEV just to clear my mind
Discovering technical writing opportunities
Working with new types of clients
Exploring design and visual work
Building projects locally

It wasn’t the path I originally planned.

But in many ways, it helped me discover skills and interests I might never have explored otherwise.

A Moment I Never Expected

Today I’ve been working as a technical writer for about a year.

And the journey has already given me moments I never expected when I started writing just to release some frustration.

At the moment I’m publishing this article, my blog on DEV has just passed 250,000 total views and 15,000 followers.

Reaching those milestones is something I could never have imagined when I wrote my first posts.

Honestly, it’s a moment when I couldn’t be prouder.

So I want to take a small moment here to say thank you to every single person who has:

read an article
left a comment
shared feedback
or simply supported my work

Whether inside the DEV community or outside it, your support has been a huge part of this journey 💙.

And it means more than you might think.

The Journey Is Still Ongoing

Today my work sits somewhere between several things I love:

programming
design
storytelling

Each one supports the others.

Writing improves how I explain technical ideas.
Design improves how I structure content visually.
Programming keeps me connected to the craft that started everything.

The payment challenges haven’t disappeared completely.

Sometimes they still cost me opportunities.

But they also pushed me toward experiences I never expected to have.

And strangely enough…

I’m grateful for that.

Because sometimes the obstacles that seem to block your path end up leading you somewhere even more interesting.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

Is Paying for an AI Interview Assistant Worth It? A Real Developer’s Breakdown (2026)

Hadil Ben Abdallah — Mon, 30 Mar 2026 08:43:24 +0000

Interviewing used to be straightforward.

You prepared your answers, practiced a few problems, maybe watched a couple of mock interviews… and hoped for the best.

But lately, something has changed.

Now there’s a whole category of tools promising to sit next to you during interviews: listening, analyzing, and even helping you respond in real time.

AI interview assistants.

And the real question isn’t what they do anymore.

It’s this:

Are they actually worth paying for?

Let’s break it down, from a developer’s perspective.

The Real Problem with Interviews (That Nobody Talks About)

Most people assume interviews are about knowledge.

They’re not.

They’re about performance under pressure.

You can know the solution… and still fail to explain it clearly.
You can understand the system… and still freeze mid-sentence.
You can be qualified… and still come off as unsure.

That gap between what you know and what you communicate is where most candidates lose.

And traditional prep doesn’t fully solve it.

Practicing alone doesn’t simulate pressure.
Watching tutorials doesn’t build real-time thinking.
Mock interviews rarely feel “real enough”.

So people started looking for something else.

Something that works during the interview, not just before it.

What AI Interview Assistants Actually Do

At a high level, these tools sit quietly in the background and help you in real time.

But the interesting part is how they do it.

A modern AI interview assistant typically:

Listens to the conversation (or reads the prompt).
Understands the question context.
Suggests structured answers instantly.
Helps you stay on track if you drift.
Adapts to behavioral + technical questions.

The goal isn’t to “cheat”.

It’s to reduce the cognitive load while you’re thinking, speaking, and solving at the same time.

That’s where tools like Final Round AI come in.

Where Final Round AI Stands Out (Without the Hype)

Instead of positioning itself as just another prep tool, Final Round AI focuses on the moment that matters most, the interview itself.

What makes it interesting isn’t just features. It’s the approach.

1. Real-time support (not just prep)

Most tools stop at practice.

Final Round AI continues into the actual interview phase, offering contextual suggestions while you’re speaking.

That changes the dynamic completely.

2. Context-aware responses

It doesn’t just throw generic answers at you.

It tries to understand:

The role you’re applying for
The type of question being asked
The direction of your current answer

And then nudges you with relevant structure.

3. Behavioral + technical balance

A lot of tools are strong in one area and weak in the other.

This one handles both:

Behavioral questions (storytelling, clarity, structure)
Technical explanations (breaking down your thinking)

Which is actually where most candidates struggle.

4. Subtle assistance (not overwhelming)

One of the biggest risks with AI tools is noise.

Too many suggestions = more confusion.

The better tools don’t try to replace you.

They just keep you aligned when it matters.

The Pros (When It Actually Helps)

Let’s be real, these tools are not magic.

But in the right situations, they can be surprisingly useful.

✅ You choke under pressure
Even strong developers blank out sometimes. Having a system that nudges you back on track can make a huge difference.

✅ You struggle with communication
You know your stuff… but explaining it clearly is hard. AI assistance helps structure your thoughts in real time.

✅ You’re interviewing frequently
Small improvements compound fast. Better clarity → better interviews → better outcomes.

✅ You want a confidence boost
Sometimes, it’s not about answers. It’s about knowing you have a safety net. That alone can change how you show up.

The Cons (Let’s Not Ignore These)

This is where most articles get biased.

So let’s keep it honest.

❌ It won’t replace real preparation
If you don’t understand the fundamentals, no tool can save you.

You still need:

Solid technical knowledge
Real project experience
Basic communication skills

❌ Over-reliance is risky
If you depend too much on AI, your natural thinking can weaken. The goal is support, not dependency.

❌ Not every interview environment allows it
Some companies have strict rules or monitored environments. You need to be aware of where and how you use these tools.

❌ It’s not “perfect”
AI suggestions can sometimes miss nuance, over-generalize, or suggest something slightly off. You still need judgment.

So… Is It Worth Paying For?

Here’s the honest answer:

It depends on where you are.

It is worth it if:

You already have the skills but struggle to express them
You’re actively interviewing and want an edge
You freeze or lose structure under pressure
You treat it as a support system, not a shortcut

It’s not worth it if:

You’re still learning fundamentals
You expect it to “carry” your interview
You rely on it instead of improving yourself

The Bigger Shift (That Most People Miss)

This isn’t just about one tool.

It’s about how interviews are evolving.

We’re moving from:

“Can you solve this problem?”

to:

“Can you think, communicate, and adapt in real time?”

And that’s exactly where AI assistants are positioning themselves.

Not as replacements.

But as performance amplifiers.

Final Thoughts

Using an AI interview assistant isn’t about shortcuts.

It’s about maximizing your performance under pressure, staying structured, and communicating clearly, especially when interviews are dynamic, fast-paced, and unpredictable.

Think of it as a confidence partner; it won’t code your answers for you, but it can help you express what you already know with clarity and precision.

If you combine solid preparation with real-time AI support, you don’t just survive interviews; you stand out.

At the end, offers go to the developer, not the assistant. But the right AI can make sure you show your best self when it matters most.

Thanks for reading! 🙏🏻 Please follow Hadil Ben Abdallah & Final Round AI for more 🧡

Final Round AI Follow

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

The Small Details That Make a Website Feel Finished (And Quietly Improve Accessibility, Performance, and Trust)

Hadil Ben Abdallah — Thu, 26 Mar 2026 07:39:13 +0000

For a long time, I thought a website was “done” when it worked.

The pages loaded.
The buttons clicked.
The API responded.

So I shipped.

And yet… something always felt unfinished.

Not broken.
Not wrong.
Just slightly careless.

It took me a while to understand this:
Most websites don’t feel incomplete because of missing features.
They feel incomplete because of missing attention.

The Details We Skip Because They Feel Too Small

There are things we don’t prioritize because they don’t block progress.

Scrollbars.
Focus states.
Text selection color.
Hover transitions.
Keyboard navigation.

None of these will crash your app.
None of them will fail a build.

So we tell ourselves:

“I’ll come back to this later.”

Most of the time… we don’t.

But users notice.
Not consciously... emotionally.

A site either feels considered... or it doesn’t.

And that feeling affects trust more than we think.

When I Started Treating CSS as a User Experience Tool

The first changes I made weren’t dramatic.
They were quiet.

Things like:

Matching ::selection colors to the brand
Adding a subtle custom scrollbar (nothing flashy, just aligned)
Making hover states consistent across buttons and links
Ensuring focus outlines were visible instead of removing them
Adding smooth but restrained transitions

None of this made my site “cooler”.

It made it calmer.

And calm is underrated on the web.

A website doesn’t need to impress.
It needs to respect attention.

Scrollbars, Selection, and the Feeling of Care

Custom scrollbars are controversial.
And honestly? They should be.

This isn’t about decoration.
It’s about alignment.

When a scrollbar slightly reflects your brand color, without harming usability, it signals intention.

Same with text selection.

Users select text constantly: copying error messages, sharing snippets, highlighting sections.

If the highlight color clashes harshly with your palette, it subtly disrupts the experience.

It’s a small adjustment.
But small adjustments compound.

Lighthouse Didn’t Just Give Me Scores; It Changed My Habits

At first, I treated Lighthouse like a scoreboard.

Green = good.
Red = fix later.

But once I paid attention, I noticed something:

Most Lighthouse improvements weren’t about hacks.
They were about discipline.

Compressing and properly sizing images
Fixing contrast instead of overriding it
Removing unused JavaScript
Avoiding layout shifts
Testing on mobile instead of assuming desktop is enough

My scores improved.

But more importantly... my sites felt lighter.

A small habit that helped: I always run Lighthouse in a fresh incognito window. That way, cached assets, extensions, or logged-in states don’t distort the results.

It keeps the feedback honest.

Accessibility Isn’t Extra Work; It’s Basic Respect

This realization changed everything for me.

Accessibility (A11y) used to feel like an advanced layer, something you “optimize for later.”

But most meaningful accessibility improvements are simple:

Proper color contrast
Visible focus indicators
Semantic HTML instead of div soup
Buttons that are actually <button> elements
Supporting keyboard navigation
Respecting prefers-reduced-motion

None of this is complex engineering.

It’s thoughtful defaults.

Accessibility doesn’t make your site worse for anyone.
It makes it usable for more people.

And when you start thinking that way, it stops feeling optional.

Mobile Performance Exposes What Desktop Hides

Desktop performance is forgiving.
Mobile is honest.

The moment I started checking mobile Lighthouse scores consistently, patterns emerged:

Oversized images
Late-loading fonts
Layout shifts from dynamic content
JavaScript I didn’t really need

Fixing these didn’t just improve metrics.

It improved trust.

Fast sites feel reliable.
Slow sites feel careless, even when they technically work.

Users may not know why something feels off.

But they feel it.

What Changed When I Started Caring About the Small Stuff

Shipping felt different.

I stopped feeling like my projects were “almost done”.

I stopped apologizing for rough edges.

My sites didn’t scream for attention.
They quietly earned it.

And interestingly, when accessibility improved, performance often improved too. Cleaner structure. Less unnecessary code. Better defaults.

Care tends to cascade.

What I No Longer Ignore

❌ Focus states
❌ Color contrast
❌ Mobile Lighthouse scores
❌ Accessibility warnings
❌ “It’s good enough” moments

Small things compound.
Neglect does too.

Final Thoughts (From One Developer to Another)

You don’t need more frameworks.
You don’t need more features.

Sometimes, you just need to slow down enough to notice what users already feel.

Good websites aren’t loud.
They’re considerate.

They don’t show off effort.
They show care.

And care, quietly, builds trust.

Take your time.
Polish the small things.

That’s what makes a website feel finished.

Wishing you calm UI, thoughtful defaults, and pride in the details, friends 💙.

What’s one “small” detail you started paying attention to that made a bigger difference than expected?

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

Spektrum: Turn Natural Language into Live Web Apps (Deploy in Minutes with AI)

Hadil Ben Abdallah — Tue, 24 Mar 2026 06:01:30 +0000

Turn a single prompt into a fully deployed web app in minutes, no setup, no infrastructure, no friction.

If you’ve ever tried to turn an idea into a working product, you already know that writing code is only a small part of the journey. The real friction usually comes from everything around it: setting up the project, deciding on the architecture, connecting services, deploying, and then iterating when things break.

At some point, what started as an exciting idea slowly turns into a process. And that process often kills momentum.

But what if you could skip most of that?

What if you could simply describe what you want to build in plain English and get back a live, deployed web application?

That’s exactly what Spektrum is designed to do.

This represents a new wave of AI app generation, where natural language becomes the interface for building real products.

What Is Spektrum?

Spektrum is a vibe coding SDK that transforms natural language into fully functional, deployed web applications. Instead of manually writing and wiring everything yourself, you define your intent, and the system takes care of execution.

In practice, that means you can describe an idea, let the AI generate the code, and receive a publicly accessible app URL in return. It’s not just a code generator; it’s a system that handles the entire lifecycle from idea to deployment.

What makes this interesting is that Spektrum doesn’t stop at generating code snippets. It actually produces complete, runnable applications that you can use, share, or integrate into your own products.

This makes Spektrum a powerful tool for AI app generation, turning natural language into web apps without traditional setup overhead.

What You Can Do with Spektrum

Spektrum opens up a faster way to go from idea to execution without getting blocked by setup or infrastructure decisions. Whether you're exploring a new concept or building something real, it lets you focus on the outcome instead of the process.

With Spektrum, you can:

Turn ideas into working web apps instantly
Build MVPs without setup overhead
Generate production-ready UI from natural language
Experiment with new product ideas quickly

This makes Spektrum especially powerful for developers who want to move fast without sacrificing real output.

Why This Matters (More Than You Think)

Before AI tooling became mainstream, teams relied heavily on planning methodologies to manage complexity. Approaches like specification by example and domain-driven design helped bridge the gap between ideas and implementation, but they still depended heavily on human coordination.

Even today, many AI tools inherit similar problems. Context gets lost between steps, developers are still responsible for managing state, and deployment pipelines remain a separate concern.

Spektrum takes a different approach by collapsing these steps into a single flow. Rather than treating coding, infrastructure, and deployment as separate phases, it handles them as one continuous process.

Compared to traditional development workflows, Spektrum removes multiple layers of setup, making the path from idea to working product significantly shorter.

The result is not just faster development, but a fundamentally different way of thinking about building software.

Explore Spektrum

Key Features That Make Spektrum Different

Spektrum isn’t just about generating code faster. It introduces a model powered by AI coding agents that handle execution, state, and deployment behind the scenes.

Here are some of the key capabilities that make that possible:

Coding Agents in the Cloud

One of the most important aspects of Spektrum is that it removes the need to manage infrastructure or execution context manually. The system handles state, code generation, and deployment in the background, allowing you to focus entirely on what you want to build.

Real-Time Monitoring

Spektrum also provides visibility into the process. You can track how your application is being generated, monitor deployment progress, and access logs when needed. This makes the system feel less like a black box and more like a collaborative tool.

From Idea to Production in Minutes

Many tools promise speed, but still require significant setup before you see results. Spektrum reduces that gap dramatically by combining project creation, task definition, and deployment into a single streamlined workflow.

Flexible, Usage-Based Pricing

The pricing model is also designed to encourage experimentation. With a token-based system and an average cost of around $0.50 per app generation, it becomes easy to test ideas without committing to heavy infrastructure costs.

How Spektrum Works (From Prompt to Live App in a Few Lines)

Using Spektrum feels surprisingly minimal. The workflow is intentionally simple, which makes it easy to experiment without dealing with setup overhead.

Here’s what that looks like in practice:

import { SpektrumSDK } from "@spektrum-ai/sdk"

const spektrum = new SpektrumSDK()

const project = await spektrum.createProject("portfolio-website")

const task = await spektrum.createTask(
  project.id,
  "Create a portfolio website for a software engineer"
)

await spektrum.codeAndDeploy(task)

const appUrl = await spektrum.getAppUrl(project.id)

console.log(`Live at: ${appUrl}`)

In simple terms:

You describe what you want
Spektrum generates the code
The app is deployed automatically
You get a live URL

At a high level, this represents a new way of building software, where natural language to web app generation becomes a practical and repeatable workflow.

What stands out here isn’t just the small amount of code. It’s the fact that everything behind the scenes, including code generation, environment setup, and deployment, is handled automatically.

This is where the experience starts to feel fundamentally different from traditional development workflows.

Getting Started with Spektrum (Two Ways)

One thing I appreciated while testing Spektrum is that it doesn’t force you into a single workflow. Depending on how you prefer to build, you can either integrate it programmatically using the SDK or use the platform directly through a visual interface.

If you’re a developer looking to embed app generation into your own product, the SDK approach gives you full control. But if your goal is to quickly test ideas, validate concepts, or just experience how fast this workflow can be, the platform UI is by far the fastest way to get started.

Option 1: Using the SDK (For Integration)

If you want to integrate Spektrum into your own application or automate workflows, you can use the SDK.

npm install @spektrum-ai/sdk

Spektrum requires Node.js 20.6.0 or higher, mainly because of modern runtime features like --env-file support.

Next, create a .env file at the root of your project and add your API key:

SPEKTRUM_API_KEY=your_api_key_here

You can get your API key by signing up on the JigJoy platform.

Once your environment is set up, you initialize the SDK:

const spektrum = new SpektrumSDK()

From there, everything revolves around two core concepts: projects and tasks.

A project is a container for your application
A task is a description of what you want to build

When you call createTask, you’re not just passing a title; you’re defining the intent and structure of your application. The more precise your description is, the better the result will be.

After defining the task, calling codeAndDeploy triggers the full pipeline:

The AI interprets your request
Generates the codebase
Prepares the environment
Deploys the application

Finally, getAppUrl returns a live, publicly accessible URL where your app is already running.

At that point, you’re no longer in a “development phase.” You already have a working product you can test, share, or iterate on.

This flow gives you full flexibility, especially if you're building something more advanced or integrating AI-generated apps into your own system.

Option 2: Using the Spektrum Platform (What I Actually Used)

In my case, I wanted to experience Spektrum the same way most developers would when discovering a new tool: quickly, without setup, and without reading too much documentation upfront. So instead of starting with the SDK, I used the Spektrum platform UI directly.

The flow is surprisingly simple and removes almost all friction.

When you open the platform, you’re guided through a step-by-step onboarding flow.

Step 1: Generate an API Key

The first step is generating your API key. Instead of manually creating environment variables or configuring anything locally, you simply click a button and the platform handles it for you.

Generate your API key directly from the platform

Within seconds, your key is generated and displayed, ready to be used if you want to switch to the SDK later.

Your API key is instantly created and ready to use

Step 2: Create Your First Project

Next, you create your first project. This acts as the container for everything you’re about to build.

Create your first project with a single click

Again, this doesn’t require writing anything manually. You can either run the suggested snippet or simply use the interface, and within a few seconds, your project is ready.

A project is created with a ready-to-use environment

Step 3: Create Your First Task

Once the project is created, the next step is defining a task.

This is where you describe what you want to build. And you can run multiple tasks within the same project.

Define what you want to build using a task

What’s interesting here is that you’re not thinking in terms of components or files. You’re defining intent, and the system takes care of translating that into an actual application.

First task is created with a single click

Step 4: Generate and Deploy the App

Once the task is defined, you simply run it.

This is the point where everything comes together.

You simply click a button, and Spektrum:

Interprets your request
Generates the full codebase
Prepares the environment
Deploys the application

Generate and deploy your first app

Within seconds, the app is built, deployed, and accessible through a live URL.

Application generated and deployed

There’s no setup, no configuration, and no deployment pipeline to manage. The entire process feels more like interacting with a system than building software in the traditional sense.

My Experience: Building a Real App with Spektrum

Instead of over-engineering the prompt, I kept it intentionally simple to see how far Spektrum could go on its own.

This was my prompt:

Create a gamified app for learning Japanese vocabulary

That’s it. One sentence.

What happened next is what genuinely surprised me.

Spektrum didn’t just generate a basic app based on that input. It expanded the idea into a fully structured experience, automatically designing a complete gamified Japanese vocabulary dashboard with multiple sections, including a hero area, progress tracking, a lesson quest path, daily missions, featured flashcards, and a leaderboard.

It also introduced reusable UI components like buttons, cards, badges, and progress indicators, along with utility helpers and polished global styling, without me explicitly asking for any of that.

In other words, it didn’t just execute the prompt. It interpreted the intent behind it and filled in the gaps like an experienced developer would.

This felt like the system was making product-level decisions, not just generating code.

Real-time monitoring showing how Spektrum interprets and builds beyond the initial prompt

A fully structured gamified app generated from a single-sentence prompt

Then I just clicked the "Deploy" button and my app was live in a few seconds. It honestly took less than a minute 😅

🚀 Try the Live App I Built

What stood out to me wasn’t just the speed, but how complete the result felt from the first iteration. The layout was structured and the UI didn’t feel randomly stitched together.

More importantly, iteration was simple. Instead of rewriting code, I could refine the prompt, adjust the requirements, and regenerate the app. That shift alone changes how you approach building.

You spend less time managing implementation details and more time thinking about the product itself.

Who Is Spektrum For?

Spektrum isn’t about replacing developers. Instead, it focuses on removing the friction that slows them down, especially in the early stages of building.

It’s particularly useful for developers building MVPs, indie hackers exploring new ideas, startups validating features, or teams looking to integrate app generation into their own platforms.

Common use cases include:

Rapid MVP prototyping
Internal tools generation
AI-powered product features
Experimenting with new ideas quickly

If your workflow often includes the thought, “This will take a few hours to set up before I even start building,” Spektrum changes that dynamic completely.

A Small Note for the Community 💙

If you’ve been exploring Spektrum or thinking about building with it, joining the JigJoy Discord is a great way to connect with the team, ask questions, and see what others are building in real time.

💬 Join JigJoy on Discord

If this project sparked your interest or gave you ideas, dropping a ⭐ on the repo is one of the simplest ways to support the team and help it reach more developers.

⭐ Star Spektrum on GitHub

Final Thoughts

There’s a moment every developer remembers when an idea turns into something real and working. It’s the moment where everything clicks, and the effort suddenly feels worth it.

Spektrum is trying to bring that moment closer by removing the layers that slow developers down. It doesn’t replace creativity or problem-solving, but it reduces the friction between intention and execution.

If the current direction of AI development continues, we may not just be writing code in the future. We may be describing systems and watching them come to life.

Tools like Spektrum aren’t just improving development. They’re redefining how software gets built.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

The Best AI Interview Assistant for Remote Tech Jobs (A Practical Guide for Developers)

Hadil Ben Abdallah — Mon, 23 Mar 2026 09:17:24 +0000

Most developers don’t fail remote interviews because they lack technical skills.

They fail because they struggle to explain their thinking clearly under pressure.

A few years ago, most developers prepared for interviews by practicing algorithms, reviewing system design concepts, and maybe running a mock interview with a friend. Today, the interview itself often happens through a laptop screen: coding platforms, video calls, shared documents, and collaborative editors.

This shift introduced a new challenge that many candidates underestimate.

In remote interviews, your ability to communicate your thinking clearly becomes just as important as the correctness of your solution.

Interviewers are not only evaluating whether you can solve a problem, they are also observing:

how you approach ambiguity
how you explain trade-offs
how clearly you structure your reasoning while under pressure
how you manage time while coding and explaining your approach

Because of this, a new category of tools has started appearing in developer workflows: AI interview assistants.

These tools are not meant to replace preparation or generate shortcuts. Instead, they aim to help candidates practice realistic interview scenarios, refine communication skills, and simulate the pressure of real interviews before the actual conversation happens.

This is why many developers are now exploring AI interview preparation tools to improve their performance in remote technical interviews.

Among the tools gaining attention recently is Final Round AI, which focuses specifically on preparing candidates for modern interview environments, especially remote ones.

To understand why tools like this are becoming relevant, it’s important to first look at what actually makes remote interviews challenging and how developers can prepare for them more effectively.

Why Remote Technical Interviews Are More Difficult Than Many Developers Expect

From the outside, remote interviews may seem easier. After all, candidates can interview from home instead of traveling to an office.

In reality, the environment introduces a different set of challenges.

During a remote interview, developers often need to manage several things at once:

solving a coding problem on a shared editor
explaining each decision verbally while coding
discussing alternative solutions and trade-offs
responding to follow-up questions in real time
handling behavioral questions through structured responses
managing silence and pressure during long video calls

Even experienced developers sometimes struggle with these conditions.

Unlike in-person interviews, there are fewer visual cues. You cannot easily read the interviewer’s reactions or adjust explanations based on body language. Silence during a call can feel longer and more stressful than silence in a room.

For many candidates, the difficulty is not the problem itself. The real challenge is organizing thoughts clearly while solving the problem live.

Common issues candidates face include:

jumping directly into coding without explaining the approach
skipping edge case analysis
providing answers without clearly structured reasoning
rushing explanations because of time pressure

These communication issues can affect interview performance even when the final solution is correct.

This is exactly why interview simulation has become one of the most effective ways to prepare.

What Is an AI Interview Assistant?

An AI interview assistant is a tool designed to help candidates prepare for technical and behavioral interviews by simulating real interview scenarios, improving communication skills, and providing structured feedback.

Unlike traditional question banks, these tools focus on how candidates explain their thinking, not just the final answer.

This makes them particularly useful for remote technical interviews, where clear communication and well-structured thinking are important.

What an AI Interview Assistant Helps You Improve

There is a misconception that AI interview tools are designed to give candidates answers during interviews.

In practice, the most valuable tools focus on practice, iteration, and communication improvement.

A well-designed AI interview assistant typically helps candidates in three main areas.

1. Interview Simulation

One of the most effective preparation techniques is practicing under realistic conditions.

Instead of simply reading questions from a list, AI interview tools can simulate interactive interview sessions. The candidate receives questions, responds verbally or through code, and must structure their explanation as if they were speaking to a real interviewer.

This type of simulation helps candidates develop the habit of thinking aloud while solving problems, which is a core expectation in technical interviews.

2. Communication and Explanation Skills

Many developers know how to solve algorithmic problems but struggle when asked to explain their reasoning clearly.

Interviewers usually want to hear:

why a specific approach was chosen
how complexity was considered
what alternative solutions were evaluated
how edge cases are handled

Practicing these explanations repeatedly helps candidates develop structured thinking and clearer communication.

3. Identifying Weak Points in Preparation

When practicing alone, it can be difficult to recognize patterns in mistakes.

AI tools can highlight recurring issues such as:

skipping reasoning steps
missing edge cases
explaining solutions too quickly
giving behavioral answers that lack structure

This kind of feedback helps candidates adjust their preparation strategy before real interviews.

How Final Round AI Approaches Interview Preparation

For developers looking for one of the best AI interview assistants for remote roles, tools like Final Round AI are designed to support realistic AI interview preparation, with a strong focus on how candidates communicate and think under pressure.

The platform attempts to replicate key elements of modern interviews, particularly those conducted remotely.

Unlike traditional coding platforms or static question lists, Final Round AI helps candidates practice explaining their reasoning rather than just arriving at the correct answer.

Several features make it particularly useful for remote interview practice.

AI Mock Interview Sessions

One of the most valuable aspects of interview preparation is simulation.

Final Round AI provides structured AI mock interview sessions where candidates can practice answering technical and behavioral questions. The goal is to recreate the pacing and interaction of real interviews rather than simply presenting a list of questions.

This format encourages candidates to explain their reasoning step by step, which mirrors the expectations of many engineering interviewers.

Interview Copilot for Structured Responses

Behavioral interviews often surprise technical candidates.

Questions about teamwork, decision-making, or project challenges require clear storytelling rather than purely technical explanations. Many developers struggle with these questions simply because they have not practiced structuring their experiences.

Final Round AI’s Interview Copilot focuses on helping candidates organize these responses so that they highlight:

the situation being described
the technical challenge involved
the decisions made during the project
the outcome and lessons learned

Practicing this structure can make behavioral responses more compelling and easier to follow.

Preparing Project Narratives

Another area where candidates frequently struggle is explaining past projects.

Interviewers often ask developers to walk through previous work in detail: architecture choices, trade-offs, failures, and improvements. Candidates who prepare these narratives beforehand usually perform significantly better.

Final Round AI can help candidates practice explaining their past work in a structured and confident way. It can also help improve how your resume presents your experience, which often influences how interviews start.

Feedback After Practice Sessions

Practice becomes far more useful when it includes feedback.

After mock interviews, candidates can review how they structured their responses and identify areas for improvement. Instead of relying on vague impressions, they receive insights that highlight specific improvements they can make before the next practice session.

Why AI-Assisted Interview Practice Is Becoming More Common

The traditional methods of interview preparation still matter.

Developers still rely on:

coding challenge platforms
system design resources
peer mock interviews

However, those methods sometimes lack continuous feedback and repetition.

AI tools introduce an additional advantage: unlimited practice with immediate insights.

Candidates can run multiple interview simulations, experiment with different explanation styles, and refine their communication skills over time.

For developers applying to remote roles across multiple companies, this ability to practice repeatedly can be particularly valuable.

Tools that simulate real interview conditions, such as AI mock interview platforms, are becoming a core part of modern technical interview preparation.

A Practical Workflow for Using AI During Interview Preparation

For developers who want to integrate AI tools into their preparation, a structured workflow helps maximize the benefits.

A balanced preparation approach might look like this:

Step 1: Strengthen technical fundamentals

Focus on core problem solving using resources like coding challenge platforms or system design materials. Strong fundamentals are still the most important part of interview preparation.

Step 2: Simulate interview conditions

Once you are comfortable solving problems, practice explaining them in interview-like scenarios. AI mock interviews can help replicate the pacing and conversational structure of real interviews.

Step 3: Analyze communication patterns

Review practice sessions and look for patterns in your responses. Are explanations clear? Are edge cases discussed? Are decisions justified?

Improving these details often makes a noticeable difference in interview performance.

Step 4: Repeat until communication becomes natural

Just like coding, communication skills improve with repetition.

Practicing multiple interview simulations helps developers become comfortable explaining complex ideas under pressure.

Final Thoughts

Remote hiring has reshaped how developers prepare for interviews.

Success is no longer defined only by solving problems correctly. Interviewers are equally interested in how candidates approach problems, explain decisions, and communicate technical ideas under pressure.

AI interview assistants are emerging as tools that help candidates practice these skills more effectively.

When used correctly, they do not replace preparation. Instead, they provide a structured environment where developers can refine their communication and build confidence before real interviews.

Platforms like Final Round AI represent part of this new wave of interview preparation tools designed specifically for modern hiring environments.

As remote hiring continues to grow, developers who can clearly explain their thinking, justify their decisions, and communicate under pressure will have a significant advantage.

And that’s exactly the skill most candidates overlook during interview preparation.

Thanks for reading! 🙏🏻 Please follow Hadil Ben Abdallah & Final Round AI for more 🧡

Final Round AI Follow

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

How to Run MCP Servers in Production (Security, Scaling & Governance for AI Tooling)

Hadil Ben Abdallah — Fri, 20 Mar 2026 07:46:16 +0000

Over the past year, MCP servers have quickly become one of the most important building blocks in modern AI systems.

Instead of limiting LLMs to static prompts, MCP (Model Context Protocol) allows models to interact with external tools and services in a structured way. That means agents can query databases, read repositories, call APIs, or trigger internal workflows while reasoning through a task.

At small scale, setting up MCP servers is surprisingly simple. You connect a tool, expose its schema, and the model can start using it almost immediately.

But once MCP tooling moves into production environments, the architecture starts to matter.

Questions appear quickly:

Who controls which tools an agent can access?
How do you prevent accidental access to sensitive systems?
How do you monitor tool usage across teams?
How do you enforce budgets and rate limits?

In other words, MCP servers introduce a new infrastructure layer: AI tooling infrastructure.

This article explores how teams are running MCP servers in production, and why introducing an AI gateway like Bifrost becomes essential for securing, scaling, and governing AI tooling.

What MCP Servers Actually Do

Before diving into infrastructure concerns, it’s helpful to understand what MCP servers provide.

The Model Context Protocol (MCP) allows LLMs to access structured tools in a standardized way. Instead of writing custom integrations for every API, developers expose tools through MCP servers that describe:

available actions
input parameters
expected outputs
permissions or constraints

For example, an MCP server might expose tools like:

search_docs
query_database
create_github_issue
deploy_service

When an AI agent reasons about a task, it can decide whether to call one of these tools.

In practice, this transforms LLMs from simple chat interfaces into autonomous problem-solving systems capable of interacting with real infrastructure.

The MCP Architecture Most Developers Start With

When developers experiment with MCP, they usually connect servers directly to the agent environment.

The architecture usually looks something like this in early MCP experiments:

Direct MCP architecture where an AI agent connects to multiple MCP servers.

At first, this approach works well.

The agent can access multiple tools, and each MCP server handles its own logic.

However, once the number of tools grows, several problems begin to appear:

Tool permissions become difficult to manage
Logging is fragmented across servers
Security policies are inconsistent
Teams configure tools differently

For a solo developer this may be manageable.
For a shared AI platform, it quickly becomes fragile.

The Hidden Problem: Uncontrolled AI Tool Access

The biggest challenge with MCP servers isn’t connecting tools. It’s controlling how those tools are used.

Imagine an engineering organization running multiple AI agents across development environments.

Each agent might have access to tools capable of:

querying internal databases
modifying infrastructure
triggering deployments
reading proprietary data

Without centralized governance, several risks emerge.

1. Security Risks

If MCP tools are configured locally, developers may accidentally expose sensitive systems.

For example:

production databases
internal APIs
CI/CD pipelines

Once the model knows a tool exists, it may attempt to use it while reasoning.

That makes permission management essential.

2. Cost and Resource Usage

Many tools invoked by AI agents generate external costs.

Examples include:

LLM API calls
database queries
search indexes
compute-heavy workflows

Without centralized governance, it becomes difficult to answer questions like:

Which team is generating the most AI cost?
Which tools are used most frequently?
Which agents trigger expensive operations?

3. Observability Challenges

Debugging AI systems is already difficult.

When tool calls are distributed across multiple MCP servers, tracing a single request can become nearly impossible.

You may need to inspect logs across:

the agent
each MCP server
external APIs

A centralized logging layer simplifies this dramatically.

Introducing the MCP Gateway Layer

This is where the concept of an MCP gateway becomes useful.

Instead of connecting AI agents directly to every MCP server, requests pass through a centralized control layer.

MCP gateway architecture where a centralized gateway routes AI agent requests to multiple MCP tool servers.

The gateway becomes responsible for:

tool discovery
permission enforcement
logging and observability
rate limiting
request validation
budget control

From the agent’s perspective, nothing changes.
But the infrastructure becomes far easier to manage.

Running MCP Infrastructure with Bifrost

This is exactly where Bifrost AI gateway fits into the architecture.

Bifrost is an open-source AI gateway designed for production LLM workloads. In addition to handling multi-provider model routing, it also supports MCP tooling infrastructure.

Instead of exposing MCP servers directly to agents, teams can route all traffic through Bifrost.

AI gateway architecture where Bifrost routes AI agent requests to multiple MCP servers.

This architecture allows Bifrost to act as a central control plane for AI tooling.

Key capabilities include:

MCP tool discovery and routing
access control and permission policies
cost tracking for tool usage
centralized observability
rate limiting and quotas

Because these policies live in infrastructure rather than local configuration, governance becomes consistent across teams.

Centralized Governance with Virtual Keys

When AI agents gain access to external tools, governance quickly becomes a critical concern.

Unlike simple API calls, MCP tools can trigger real actions: querying databases, interacting with internal APIs, or modifying resources. Without proper controls, a misconfigured agent could easily execute operations it should never have access to.

A practical solution is to move governance away from individual applications and enforce it at the infrastructure layer.

Bifrost approaches this problem through Virtual Keys, which act as programmable access policies for AI workloads.

Instead of distributing unrestricted API keys to every agent or service, teams issue Virtual Keys that define exactly what an AI workload is allowed to do.

A single Virtual Key can enforce rules such as:

maximum monthly spending for LLM usage
request throughput limits
allowed or restricted model providers
access permissions for specific MCP tools

For example, an organization might create separate keys for different teams or environments.

A development key might allow access to internal documentation tools and staging APIs, while production automation keys might be restricted to read-only tools.

Requests routed through Bifrost include the Virtual Key header:

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "x-bf-vk: vk-engineering-main" \
  -d '{ ... }'

Before the request reaches a model provider or MCP server, the gateway evaluates the policy associated with that key.

If the request violates the defined constraints, it is rejected immediately.

This approach shifts security decisions from application logic to infrastructure policy, which is significantly easier to audit and maintain as systems grow.

Observability for AI Tooling

Another major advantage of routing MCP traffic through a gateway is observability.

Every request passing through Bifrost can capture metadata such as:

prompt inputs
tool calls triggered by the model
selected model provider
token usage
latency
cost
error messages

Logs are accessible through the built-in dashboard:

http://localhost:8080/logs

This provides a unified view of how AI agents interact with tools across the entire system.

Instead of debugging across multiple services, engineers can trace requests directly from the gateway layer.

Performance and Scalability

Once MCP tooling becomes part of a production system, the number of interactions between models and tools increases rapidly.

Agents might query multiple services during a single task: retrieving documentation, inspecting logs, and triggering automation pipelines. In larger environments, this traffic can grow to thousands of tool calls per minute.

At that scale, infrastructure design matters.

Bifrost is implemented in Go and built specifically for high-concurrency workloads. The gateway is capable of handling large volumes of AI requests while simultaneously performing several critical operations:

request routing to different model providers
enforcement of policy rules
logging of tool interactions
tracking token consumption and cost

Because these responsibilities are centralized in the gateway layer, individual applications remain lightweight. They simply send requests to a single endpoint while the gateway handles the operational complexity behind the scenes.

In practice, this design allows organizations to support:

large fleets of AI agents
multiple MCP tool servers
shared AI infrastructure across teams

without turning the application layer into a tangled web of integrations.

How MCP Servers Changed the Way I Build AI Workflows

When I first started experimenting with MCP servers, the setup was surprisingly simple. I connected an AI agent to a few MCP tools, exposed their schemas, and the model could immediately start using them to search documentation, query APIs, or inspect code.

At first, everything worked smoothly.

But as I added more tools and MCP servers, the system started becoming harder to manage. Understanding which tool an agent had used, tracking logs, and debugging tool failures often meant jumping between multiple services.

The complexity didn’t come from the tools themselves, but from how they were connected.

Introducing a gateway layer in front of the MCP servers made a big difference. Instead of agents connecting directly to every tool, all requests passed through a single control point.

That small architectural change made the system much easier to operate.

Tool usage became visible in one place, policies could be applied consistently, and adding new tools no longer required updating multiple integrations.

For small experiments, direct MCP integrations work fine. But once MCP servers start powering real workflows, treating them as AI infrastructure rather than just tools makes everything significantly easier to manage.

When You Actually Need MCP Governance

Not every project requires a full MCP governance layer.

For prototypes or personal projects, direct MCP connections are usually sufficient.

However, once AI systems interact with real infrastructure, centralized governance becomes important.

You’ll likely benefit from an MCP gateway when:

multiple MCP servers are deployed
AI agents interact with production systems
teams share AI tooling infrastructure
security policies must be enforced
cost control becomes necessary

At that point, treating MCP as infrastructure rather than tooling becomes the right architectural decision.

Final Thoughts

MCP servers are transforming how AI systems interact with software environments.

Instead of limiting models to static prompts, developers can give them access to tools capable of retrieving data, triggering workflows, and modifying systems.

That power comes with new operational challenges.

As the number of tools grows, teams need ways to control access, track usage, and enforce governance policies.

Introducing an MCP gateway layer solves many of these challenges by centralizing security, observability, and cost control.

If you're interested in how organizations build full multi-provider AI infrastructure around gateway architectures, I explored that topic in more detail in this guide:
How to Build a Multi-Provider LLM Infrastructure with an AI Gateway (OpenAI, Claude, Azure & Vertex).

For teams building production AI platforms, Bifrost AI gateway provides the infrastructure necessary to run MCP tooling safely at scale.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

How to Use Bifrost CLI with Any AI Model (Claude Code, Codex, Gemini & Opencode)

Hadil Ben Abdallah — Thu, 19 Mar 2026 07:04:33 +0000

Most AI coding tools work well... until you try to use more than one model.

If you're using Claude Code, Codex CLI, or Gemini CLI, you've probably hit the same wall:
switching between models is slow, messy, and full of configuration overhead.

At first, everything feels simple. You install a tool, connect it to a model, and start building. But as your workflow grows, so does the complexity. Different tools require different setups, environment variables start piling up, and even small changes become frustrating.

Bifrost CLI (Command Line Interface) solves this by letting you use any AI model with any coding agent from one interface.

No repeated setup. No environment variable chaos. No vendor lock-in.

In this guide, you'll learn exactly how Bifrost CLI works, why it matters for modern development workflows, and how to set it up in minutes.

What is Bifrost CLI?

Bifrost CLI is an interactive AI CLI tool that acts as a unified interface between coding agents (like Claude Code, Codex CLI, and Gemini CLI) and multiple AI providers.

Instead of manually configuring each tool, managing environment variables, or switching between provider-specific setups, Bifrost lets you launch everything from a single command. You simply choose your agent, select a model, and start working.

Under the hood, it connects your tools to a centralized AI gateway, handling authentication, routing, and configuration automatically.

This makes it possible to run a true multi-model workflow without changing how you work, just with far less friction.

What Bifrost CLI Actually Solves

The problem Bifrost CLI addresses isn’t just tool fragmentation; it’s workflow complexity.

When you start working with multiple AI models, things break down quickly.

Each coding agent has its own setup. Switching models means updating environment variables, reconfiguring providers, or even restarting sessions. What starts as a simple setup turns into constant friction.

Bifrost CLI removes that friction by centralizing everything behind a single interface.

Instead of configuring each tool separately, the CLI handles API keys, base URLs, model selection, and provider routing automatically.

In practical terms, this means you can use any model from any provider without interrupting your workflow.

You keep using your favorite tools, but eliminate the operational overhead that slows you down.

Explore Bifrost CLI

Why This Matters for Real Development Workflows

If you're already working with multiple AI models or experimenting with coding agents, you've probably started running into these limitations.

At some point, the problem stops being about "which model is better" and becomes an infrastructure question.

How do you route requests?
How do you switch providers without rewriting everything?
How do you keep visibility and control across all of it?

If you're building coding agents or developer tools, this pattern becomes even more important at scale.

I broke down the full architecture behind multi-provider AI gateways (and how tools like Bifrost fit into it) here: How to Build a Multi-Provider LLM Infrastructure with an AI Gateway (OpenAI, Claude, Azure & Vertex)

Different models excel at different things. For example, you might prefer one model for code generation, another for debugging, and another for long-context reasoning.

Without a unifying layer, switching between these models requires manual reconfiguration every time. That friction adds up quickly and slows down development.

Bifrost CLI removes that friction entirely by turning model selection into a runtime decision instead of a setup problem.

This is where having a structured multi-model workflow becomes critical.

How Bifrost CLI Works Under the Hood

Bifrost is an open-source AI gateway that introduces a layer between your tools and AI providers.

Instead of your CLI tool talking directly to OpenAI, Anthropic, or Google, everything routes through Bifrost.

The architecture looks like this:

Your CLI Tool (Claude / Codex / Gemini / Opencode)
→ Bifrost CLI
→ Bifrost Gateway
→ Any AI Model (OpenAI, Anthropic, Google, etc.)

This design has an important implication.

Bifrost acts as a control layer between developer tools and multiple AI providers

Your tools no longer need to know anything about providers. They simply send requests, and Bifrost handles routing, authentication, and configuration.

Getting Started with Bifrost CLI

One of the most impressive aspects of Bifrost CLI is how quickly you can get started.

First, you need to run the gateway:

npx -y @maximhq/bifrost

This starts the gateway locally, typically on http://localhost:8080.

Then, in a separate terminal, launch the CLI:

npx -y @maximhq/bifrost-cli

If you’ve already installed it, you can simply run:

bifrost

From there, everything happens interactively.

The Setup Flow (What Actually Happens)

Instead of forcing you to configure everything manually, the CLI walks you through a structured setup process.

First, you provide the base URL of your gateway. In most local setups, this will be:

http://localhost:8080

Next, you can optionally enter a virtual key. This is used for authentication and is stored securely in your operating system’s keyring, not in plaintext files.

Then comes one of the most important steps: choosing your coding agent.

You can select from Claude Code, Codex CLI, Gemini CLI, or Opencode. If the tool is not installed, Bifrost will install it automatically using npm. This removes another common source of friction in CLI-based workflows.

After selecting the agent, the CLI fetches available models directly from the gateway. You can search through them interactively or type a model identifier manually.

For example:

openai/gpt-5
gemini/gemini-2.5-pro
anthropic/claude-sonnet

Once everything is selected, you simply press Enter to launch your session.

At that moment, Bifrost configures everything for you, including API keys, environment variables, and provider-specific settings, without any manual intervention.

Running Multiple AI Agents in Parallel

One of the most powerful features of Bifrost CLI is its tabbed terminal interface.

Unlike traditional CLI tools that exit after a session, Bifrost keeps everything running inside a persistent environment. You can launch multiple agents at the same time and switch between them instantly.

For example, you might run:

Codex with GPT-5 for code generation
Gemini for reasoning-heavy tasks
Claude Code for file operations and tooling

Each session runs in its own tab, and you can switch between them using keyboard shortcuts.

This transforms your terminal into a multi-agent workspace instead of a single-threaded tool.

Why the Tabbed Interface Changes Everything

At first glance, the tab system might seem like a small feature. In practice, it completely changes how you work.

Instead of stopping one task to start another, you can keep multiple flows running in parallel. One agent can analyze a codebase while another generates a feature and a third debugs an issue.

This kind of workflow is difficult to achieve with standard CLI tools.

Bifrost makes it feel natural.

Advanced Features That Matter in Practice

Beyond the basic setup, Bifrost CLI includes several features that become increasingly valuable as your workflow grows.

First, it eliminates the need for environment variables. You no longer have to export API keys or manage provider-specific configurations manually. Everything is handled automatically.

Second, it stores sensitive data securely using your operating system’s keyring. This is especially important for teams or shared environments where security matters.

Third, it integrates with MCP when using Claude Code. This allows your agent to access tools and external systems without requiring additional setup commands.

Finally, it supports persistent sessions. Your last configuration is saved, so the next time you launch the CLI, you can resume instantly without repeating the setup process.

Configuration and Flexibility

Bifrost CLI stores its configuration in a local file:

~/.bifrost/config.json

A typical configuration might look like this:

{
  "base_url": "http://localhost:8080",
  "default_harness": "claude",
  "default_model": "anthropic/claude-sonnet"
}

This allows you to maintain consistent setups across sessions while still being able to override settings when needed.

Common Use Cases for Bifrost CLI

Here are a few real-world scenarios where Bifrost CLI becomes especially useful:

Multi-model development: Use GPT-5 for generation, Claude for tooling, and Gemini for reasoning
AI experimentation: Quickly compare outputs across providers without reconfiguration
Team environments: Standardize how developers interact with different AI models
Agent workflows: Run multiple coding agents in parallel with different models

These are the kinds of scenarios where Bifrost CLI starts to provide real leverage in your workflow.

When Bifrost CLI Becomes Essential

Not every project needs a tool like Bifrost.

If you are working on a small prototype with a single model, direct integration is usually enough.

However, the moment you start working with multiple models, multiple tools, or team environments, the complexity grows quickly.

That’s when a unified interface becomes valuable.

Bifrost CLI simplifies:

Switching between models
Managing multiple agents
Maintaining consistent configuration
Scaling workflows across projects

It turns what would normally be a fragmented setup into a cohesive system.

Final Thoughts

The real value of Bifrost CLI is not just convenience. It is the shift in how you think about AI tools.

Instead of choosing a tool based on its default model, you choose the best model for the task and use it through the tool you already like.

That separation between tools and models is what makes modern AI workflows scalable.

Once you experience that flexibility, going back to single-provider setups feels limiting.

If you're working with multiple AI models, Bifrost CLI is one of those tools that quickly becomes hard to live without.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use

How to Build a Multi-Provider LLM Infrastructure with an AI Gateway (OpenAI, Claude, Azure & Vertex)

Hadil Ben Abdallah — Thu, 12 Mar 2026 08:14:39 +0000

Most AI applications start simple.

A developer picks a model, integrates an API, and ships a feature. For many teams, that model is often OpenAI GPT-4, Claude, or another popular LLM provider.

At small scale, this approach works perfectly.

But once the system grows, especially when multiple teams, environments, and workloads are involved, a new set of challenges starts appearing:

Different tasks perform better on different models
Costs become difficult to track
Failover between providers becomes necessary
Observability becomes fragmented
Switching providers requires code changes

In other words, the architecture becomes tightly coupled to individual APIs.

This is exactly where AI gateway infrastructure starts to matter.

Instead of connecting your application directly to multiple model providers, you introduce a central gateway layer responsible for routing, governance, logging, and provider translation.

In this article, we’ll break down how to build a multi-provider LLM infrastructure using an AI gateway that connects to:

OpenAI
Anthropic (Claude)
Azure OpenAI
Google Vertex AI

We’ll also explore how Bifrost AI gateway can serve as the control plane that makes this architecture scalable in real production environments.

Why Multi-Provider LLM Infrastructure Is Becoming Standard

Early AI systems typically rely on a single provider.

That decision often comes from convenience rather than architectural planning. The API is easy to integrate, the documentation is clear, and the initial results are impressive.

However, relying on a single model provider introduces several risks that become obvious as usage increases.

1. Vendor Lock-In

Every provider exposes slightly different APIs, authentication models, and request formats. Once your application integrates deeply with one provider, switching becomes expensive.

For example:

OpenAI uses its own chat completion format
Anthropic uses a different message structure
Vertex AI has its own authentication and endpoint model
Azure adds an additional abstraction layer

Without an abstraction layer, migrating between providers often requires rewriting parts of your application.

2. Cost Optimization

Different models excel at different workloads.

For example:

Task	Ideal Model
Code generation	Claude Sonnet
High-volume classification	GPT-4o Mini
Large context reasoning	Claude Opus
Enterprise workloads	Vertex AI

A multi-provider architecture allows requests to be routed dynamically based on cost, latency, or capability.

3. Reliability and Failover

Even the most reliable AI providers occasionally experience outages or degraded performance.

A multi-provider architecture allows systems to implement:

Automatic provider failover
Latency-based routing
Regional fallback models

These are standard reliability patterns in modern distributed systems.

The Architecture Most Teams Start With

Without a gateway layer, applications usually connect directly to each provider.

The architecture often looks like this:

Application
   │
   ├── OpenAI API
   ├── Anthropic API
   ├── Azure OpenAI
   └── Vertex AI

At first glance, this seems manageable.

But once additional components are introduced, like agents, MCP tools, or internal APIs, the number of integrations grows quickly.

If you're building coding agents or developer tools, I also wrote about how AI gateways integrate with terminal agents like Claude Code: How to Scale Claude Code with an MCP Gateway

Your application ends up managing:

authentication for each provider
request routing logic
cost tracking
error handling
retry logic
logging and monitoring

As the system grows, that responsibility becomes difficult to maintain inside the application layer.

Direct integrations quickly become complex as the number of providers grows, while an AI gateway centralizes routing and governance.

Introducing the AI Gateway Architecture

A more scalable design introduces an AI gateway between your application and the providers.

       Application
            │
            │
        AI Gateway
            │
 ┌──────────┼──────────┬───────────────┐
 │          │          │               │
OpenAI  Anthropic  Azure OpenAI    Vertex AI

Instead of integrating each provider directly, the application sends requests to a single endpoint.

The gateway handles:

provider routing
API translation
authentication management
cost tracking
logging and observability
rate limiting and governance

From the application’s perspective, the system becomes dramatically simpler.

Where Bifrost Fits in This Architecture

This is the exact problem Bifrost AI gateway was designed to solve.

Bifrost AI gateway is an open-source AI gateway built in Go, designed for production-grade LLM traffic. Instead of embedding provider logic inside your application, Bifrost sits between your system and the model providers.

       Application
            │
            │
    Bifrost AI Gateway
            │
 ┌──────────┼──────────┬───────────────┐
 │          │          │               │
OpenAI  Anthropic  Azure OpenAI    Vertex AI

In practice, Bifrost acts as both a multi-provider LLM gateway and a central control plane for AI workloads.

Key capabilities include:

Multi-provider model routing
API translation between providers
Token usage analytics
Cost tracking
Observability dashboards
Rate limiting and quotas
Budget enforcement
MCP tool routing

Because the gateway centralizes these concerns, your application can remain provider-agnostic.

Running Bifrost as the Gateway Layer

Running Bifrost locally or in infrastructure is intentionally simple.

Example setup:

npx -y @maximhq/bifrost

Or with Docker:

docker run -p 8080:8080 maximhq/bifrost

Once the gateway is running, applications can route their requests through it.

For example:

POST http://localhost:8080/v1/chat/completions

From that point forward, the gateway becomes responsible for forwarding requests to the appropriate provider.

Dynamic Model Routing Across Providers

One of the most powerful features of an AI gateway is dynamic model routing.

Instead of hard-coding a specific model into your application, the gateway can determine which provider should handle the request.

Example model selection:

/model openai/gpt-4o-mini
/model anthropic/claude-sonnet
/model vertex/gemini-pro

Because the gateway handles API translation, the application does not need to know the underlying provider format.

This architecture unlocks several important capabilities:

A/B testing models across providers
switching providers instantly
optimizing cost per request
benchmarking model performance

For organizations running large AI workloads, this flexibility quickly becomes essential.

Centralized Observability for AI Systems

One of the most overlooked problems in AI infrastructure is lack of visibility.

When applications connect directly to providers, logs and metrics are scattered across different services.

An AI gateway centralizes this data.

With Bifrost, each request flowing through the gateway can capture:

the input prompt
tool calls triggered by the model
the provider and model used
token consumption
request latency
total cost
error information

Logs can be viewed through the built-in dashboard:

http://localhost:8080/logs

Having this centralized view makes debugging AI systems significantly easier.

Instead of searching across multiple services, teams can observe model behavior directly at the infrastructure layer.

Cost Governance for Production AI Systems

Another challenge organizations face is runaway LLM costs.

Without governance, developers may unknowingly route high-volume workloads to expensive models.

Bifrost introduces a concept called Virtual Keys that enforce cost and usage policies.

Virtual Keys can define:

monthly dollar budgets
token usage limits
request rate limits
model allow-lists
provider restrictions

Example configuration:

Engineering team access:

Monthly budget: $200
Allowed models: Claude Sonnet, GPT-4o Mini
Restricted models: GPT-4o Full

Requests can then be enforced using headers:

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "x-bf-vk: vk-engineering-main" \
  -d '{ ... }'

If a request exceeds its budget or violates policy, enforcement happens automatically at the gateway layer.

That shift moves governance from client configuration to infrastructure policy.

Personal Experience: Why Gateways Become Necessary

When experimenting with multi-provider AI systems, many developers start by integrating several APIs directly into their application.

I followed the same approach initially.

It worked well while experimenting with a single model provider.

But once additional components were introduced, multiple models, agent tools, and internal APIs, the architecture quickly became difficult to manage.

Switching models required code changes. Logs were scattered across services. Debugging agent behavior became time-consuming.

Introducing a gateway simplified everything.

The application connected to a single endpoint, while the gateway handled routing, logging, and provider translation behind the scenes.

That architectural shift made the system easier to scale and much easier to operate.

Performance Considerations

A common concern with gateway architectures is added latency.

A well-designed gateway should introduce minimal overhead.

Because Bifrost is implemented in Go, it is optimized for high concurrency and low-latency routing.

Measured overhead for routing and logging operations is extremely small, on the order of microseconds per request, which makes the gateway suitable for high-volume AI systems.

This performance profile allows Bifrost to support:

chat applications
coding agents
AI APIs
production LLM platforms

without becoming a limiting factor.

When an AI Gateway Actually Makes Sense

Not every project requires an AI gateway.

For small prototypes or single-developer experiments, direct provider integrations are often sufficient.

You may not need a gateway if:

your system uses a single model provider
cost governance is not important
there are no shared environments

However, the architecture becomes valuable when:

multiple LLM providers are involved
teams share AI infrastructure
workloads require cost optimization
governance policies must be enforced
observability and debugging are critical

In those environments, centralizing control at the gateway layer prevents significant complexity later.

Final Thoughts

As AI systems grow more complex, the challenge shifts from simply calling a model API to managing a full LLM infrastructure layer.

A multi-provider architecture allows teams to avoid vendor lock-in, optimize cost per workload, and maintain resilience when providers experience outages.

Introducing an AI gateway is one of the simplest ways to achieve that flexibility.

Instead of embedding provider logic throughout your application, the gateway becomes a centralized control plane responsible for routing, governance, and observability.

That architectural decision allows your system to remain adaptable as the AI ecosystem continues evolving.

And in environments where multiple providers, teams, and tools interact, solutions like Bifrost AI gateway make that architecture far easier to operate in practice.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Content Writer (250K+ readers) I turn brands into websites people 💙 to use