DEV Community: Ladipo Samuel

The adrenaline of a new month: Merlin!

Ladipo Samuel — Fri, 01 May 2026 18:05:52 +0000

“I want to earn $10B every second this month. I want to build Jumia in 3 hours… MERLINNNN!”

Now, if that energy could actually be sustained 24 hours a day for the entire month, maybe it works. But you’re not a robot, so let’s be real about it.

We have 31 days this month. That’s a lot of time to achieve meaningful progress, but still not enough to do everything at once. Habits don’t form in a day, and hobbies don’t stick in 3 hours. If you want to be productive, consistency in the right direction is what matters. This applies to developers and honestly anyone trying to get better at something.

In April, I tried this approach, almost all of it. What stood out was that no matter how tough some days were, I showed up about 99% of the time. That alone made a difference. It’s not easy, and if you want to reach a new level, it won’t come from scrolling all day. It comes from intentional effort and some level of planning.

A lot of people will tell you to create a timetable. Then you pack everything into it. Day one, you’re fully energized. Day two, still going. By day three, reality starts to hit. The plan is too heavy. It becomes overwhelming, then procrastination sets in. Before you know it, the month is gone and you’re relating a little too much to “successfully wasted the month.” It sounds like a joke, but it’s real for a lot of people.

So what actually works? Start doing. Start small but be intentional. Set a plan you’re sure you can follow. Not something that looks impressive, but something realistic. Let each day end with you doing or learning something, no matter how small. After a week, adjust slightly. Add just a little more. Build gradually.

You might not do something huge by the end of the month, but you would have made real progress. And that counts.

Some days, you won’t feel like doing anything. That’s normal. Rest if you need to, but don’t abandon the plan. Keep it simple enough that you can always return to it.

Rooting for you this month. You can do more than you think, just start small and stay consistent.

Cencori: A Serverless Infrastructure Layer for Secure and Scalable AI Applications

Ladipo Samuel — Thu, 30 Apr 2026 16:32:17 +0000

Abstract

The rapid adoption of large language models (LLMs) has accelerated the development of intelligent applications across domains such as healthcare, finance, and customer service. However, building production-grade AI systems remains a complex engineering challenge due to fragmented tooling, security vulnerabilities, and the operational overhead of orchestrating multi-model workflows. This paper presents Cencori, a serverless infrastructure layer designed to unify model routing, persistent memory, agent orchestration, and security enforcement within a single backend platform. Unlike existing solutions that address these concerns in isolation, Cencori integrates them at the infrastructure level, enabling developers to build reliable and scalable AI systems with reduced complexity. We analyze the system architecture of Cencori, evaluate its core components, and position it within the broader AI tooling ecosystem. Our findings suggest that infrastructure-centric approaches significantly improve system robustness, developer productivity, and security in modern AI applications.

I. Introduction

Large language models (LLMs) have evolved from experimental research artifacts into foundational components of modern software systems. Their ability to generate, reason, and interact using natural language has enabled a new class of applications, including conversational agents, automated decision systems, and intelligent assistants.

Despite this progress, deploying LLM-based systems in production introduces significant challenges. Real-world AI applications are not composed of isolated model calls; rather, they operate as distributed systems requiring reliability, scalability, and security. Developers must manage multiple model providers, handle latency and failure scenarios, maintain conversational context, and protect systems against vulnerabilities such as prompt injection and data leakage.

Current development practices rely on a combination of independent tools: model routers, orchestration frameworks, vector databases, and security filters. While effective in isolation, these tools collectively increase system complexity and operational overhead.

Cencori addresses this fragmentation by introducing a unified infrastructure layer for AI systems. It abstracts core concerns such as routing, memory, orchestration, and security into a single platform, enabling developers to focus on application logic rather than system integration.

This paper presents the design and architecture of Cencori, evaluates its capabilities, and discusses its implications for building production-grade AI systems.

II. Background and Related Work

The ecosystem of AI development tools can be broadly categorized into three areas: model access layers, orchestration frameworks, and frontend integration tools.

Model access platforms provide unified interfaces for interacting with multiple LLM providers, enabling flexibility and redundancy. However, they are typically limited to request forwarding and lack deeper integration with application state or workflow logic.

Orchestration frameworks enable developers to chain model calls and construct multi-step workflows. While powerful, these frameworks often require extensive configuration and do not inherently address system reliability or security concerns.

Frontend-focused AI tools simplify the integration of AI into user interfaces but depend heavily on backend systems that developers must implement separately.

Existing research has also highlighted emerging risks in LLM systems, particularly prompt injection attacks and data leakage [1], [2]. These challenges underscore the need for infrastructure-level solutions that incorporate security by design.

Cencori differentiates itself by combining routing, memory, orchestration, and security into a unified backend abstraction. This approach aligns with principles from distributed systems design, where complexity is managed through layered architectures and well-defined interfaces.

III. System Architecture
A. Architectural Overview

Cencori adopts a layered architecture that separates concerns while maintaining tight integration between system components. The overall structure is illustrated as follows:

Client Applications (Web, Mobile, APIs)
↓
Unified API Gateway
↓
Intelligent Routing Engine
↓
Multi-Provider LLM Layer
↓
Memory and State Management
↓
Security and Policy Enforcement

This architecture enables modularity while ensuring that critical functions such as routing and security are consistently applied across all interactions.

B. Core Components
1) API Gateway

The API gateway serves as the primary interface between client applications and the platform. It is designed to be compatible with widely adopted APIs, allowing developers to integrate Cencori with minimal changes to existing systems.

2) Routing Engine

The routing engine dynamically selects LLM providers based on factors such as latency, cost, and availability. It supports fallback mechanisms, ensuring continuity of service in the event of provider failure.

This dynamic selection process improves system resilience and enables cost-performance optimization at runtime.

3) Memory Layer

Cencori incorporates a persistent memory system that allows applications to maintain context across interactions. This transforms inherently stateless model interactions into stateful experiences, improving coherence and usability in conversational systems.

4) Security Layer

Security is integrated directly into the infrastructure. The platform includes mechanisms for prompt injection detection, PII redaction, and input/output validation.

By embedding these protections within the request pipeline, Cencori reduces the likelihood of vulnerabilities and ensures consistent enforcement across applications.

5) Agent Orchestration

Cencori supports the construction of multi-step workflows through agent orchestration. This enables developers to define structured processes involving multiple model interactions, external tools, and conditional logic.

IV. Key Features

Cencori’s design emphasizes the integration of multiple capabilities into a cohesive system.

A. Dynamic Model Routing

The platform enables seamless switching between model providers, improving reliability and enabling fault tolerance in distributed environments.

B. Persistent Context Management

The memory layer supports context retention across sessions, allowing applications to deliver more coherent and personalized interactions.

C. Integrated Security Mechanisms

Built-in protections ensure that applications are safeguarded against common vulnerabilities without requiring additional implementation effort.

D. Workflow Automation

Agent orchestration enables the development of complex AI systems that go beyond simple prompt-response interactions.

V. Implementation and Integration

Cencori is designed for ease of adoption. Its compatibility with existing APIs allows developers to integrate the platform by modifying configuration parameters rather than rewriting codebases.

The serverless architecture eliminates the need for infrastructure management, enabling automatic scaling and reducing operational overhead. This design aligns with modern cloud-native development practices and supports rapid deployment of AI applications.

VI. Applications

Cencori’s capabilities make it suitable for a wide range of applications:

Conversational AI systems with persistent memory
Healthcare applications requiring secure data handling
Financial systems leveraging AI for analysis and automation
Customer support platforms handling complex, multi-step queries

In each case, the platform enhances reliability, scalability, and security.

VII. Evaluation
A. Advantages

Cencori offers several benefits:

Reduced architectural complexity through unified infrastructure
Improved reliability via dynamic routing and failover mechanisms
Enhanced security through integrated protections
Scalability enabled by serverless design B. Limitations

Despite its advantages, certain limitations remain:

Dependence on a centralized platform introduces vendor lock-in
Abstraction may limit low-level customization
Usage-based pricing models require cost monitoring at scale

VIII. Future Work

Future developments may include:

Support for multimodal AI systems
Edge deployment for latency-sensitive applications
Advanced routing strategies driven by real-time metrics
Integration with model training and fine-tuning pipelines

IX. Conclusion

The development of AI applications is increasingly defined by system-level challenges rather than model capabilities alone. Cencori addresses this shift by introducing a unified infrastructure layer that integrates routing, memory, orchestration, and security.

By abstracting these concerns, the platform reduces development complexity while improving system reliability and scalability. As AI systems continue to evolve, infrastructure-driven approaches such as Cencori are likely to play a critical role in enabling robust and production-ready applications.

Am I Really in Tech or Just Learning Languages?

Ladipo Samuel — Fri, 17 Apr 2026 14:16:19 +0000

Am I really in tech or not?

Honestly, there’s no “in between” in tech. You are either building, learning, or you are just… watching from the sidelines.

A lot of people quietly struggle with this question. What actually qualifies someone as a developer? Do I need 10 languages? A big job title? A fancy GitHub?

Let’s clear that up.

To be in tech simply means you are specialized in a direction and actively building within it. Even systems that look like they “know everything” are still built on deep specialization under the hood.

Now the real confusion usually starts here:

“Is Python enough to call myself a developer?”
“Do I need TypeScript, Go, Rust, Java, and maybe one alien language?”

The honest answer is yes… Python is enough. TypeScript is enough. But not in the way most people think.

And this is where people start entering what I call the “language hopping loop” 😄

You learn Python.
You build a few projects.
Then someone says “JavaScript is where the jobs are.”
You switch.
Then another person says “Go is better for scalability.”
You switch again.

At that point, you are not learning deeper systems anymore, you are basically doing load balancing… but for your attention span 😭

And the result?

You might even land interviews, but when they ask deeper questions like system design, caching strategies, or how your API handles concurrency, things start feeling… blurry.

Because the issue was never the language.

There is no “best language”. There is only context.

Python is not better than TypeScript. TypeScript is not better than Python. They are just tools optimized for different workloads, like how caching, indexing, and database choice depend on the system you are building.

So how do you actually get into tech properly?

Not the usual “learn a language, build a todo app, become senior engineer in 2 weeks” story 😄

The real path is deeper than that.

Start with a language. Yes.
But don’t stay at surface level.

Go beyond syntax:

understand how memory is managed
learn how APIs actually handle requests under the hood
explore scalability concepts like load balancing and caching
break things, fix them, rebuild them better

Think of it like mathematics.

You don’t stop at BODMAS and call it a day. You move into algebra, calculus, and eventually deeper problem solving where everything connects.

Tech is the same.

Once you pick a path, start building real things. Then revisit them as your knowledge grows. Improve the architecture. Refactor the design. Optimize performance. That is where growth actually happens.

And over time, something interesting happens.

You stop saying “I know Python” and start saying “I understand systems.”

That shift is what I like to call the transition from learning mode to improvement mode.

It’s a bit like solo leveling 😄

And here’s the final truth:

Once you deeply understand one stack, moving to another becomes easier. Not because it is similar, but because your thinking has already adapted to complexity.

That’s when you are truly in tech.

Not because you know everything, but because you know how to learn anything.

Every week, I will be sharing more of these, focused on practical technical growth, deeper understanding of systems, and lessons that actually help you become a better builder in tech.

If you’re on the same journey, stick around. There’s more coming!!!

Testing API Security with Cencori: A Case Study Using InsecurePay

Ladipo Samuel — Fri, 03 Apr 2026 19:25:10 +0000

Before running any security scans, I needed something meaningful to test. So I built InsecurePay, a simple payment API designed to mirror real-world payment systems, but intentionally implemented with relaxed security.

At its core, InsecurePay handles three main functions:

Authentication — a basic login endpoint that returns a token
Payments — an endpoint that processes card payments
Transactions — an endpoint to view processed payments

The project is built with Node.js and Express, and it follows a structure that reflects many real backend systems:

Routes handle incoming requests
Controllers manage the business logic
A mock database simulates data storage

How InsecurePay Works

When a user sends a payment request, the API:

Accepts card details and payment information
Simulates processing (no real payment gateway is used)
Stores the transaction
Returns a response containing the transaction details

At first glance, everything works as expected. You can log in, make a payment, and receive a successful response.

However, despite being functional, the API had some serious security concerns:

Sensitive data like card numbers and CVV were exposed in responses
Secrets were hardcoded directly into the codebase
Critical routes, such as payments, lacked proper protection
Logging exposed more information than necessary

None of these issues broke the application, but they violated basic security expectations. That was intentional.

InsecurePay wasn’t designed to be perfect. It was built to reflect real-world flaws so they could be identified and addressed.

At this point, I had a working API, but I already knew it wasn’t secure. So I decided to test it using Cencori Scan, an AI-powered tool that detects security issues in codebases and suggests fixes. It can identify hardcoded secrets such as API keys and passwords, flag PII leaks like emails and card details, and detect vulnerable routes and unsafe coding practices.

The goal was simple: could this tool detect real vulnerabilities in my project, and more importantly, help fix them?

I ran the scan using:

npx @cencori/scan

Results from the Scan

Cencori flagged several critical issues:

Secrets in code — API keys and passwords were hardcoded
PII exposure — card numbers, CVV, and emails were returned in responses
Unprotected routes — sensitive endpoints lacked proper authorization checks
Unsafe logging — request payloads exposed sensitive information

While nothing broke, the security posture of the application was clearly weak.

Fixing the Issues with Cencori

I enabled Cencori’s auto-fix feature to address the problems more efficiently. To use Cencori Scan, you follow these steps:

Step 1: Get an API key

I generated a free API key from the dashboard and added it to my environment:

$env:CENCORI_API_KEY="your_api_key_here"

Step 2: Run auto-fix

npx @cencori/scan --fix

Cencori then analyzed each issue, suggested fixes, and updated parts of the code automatically.

What Changed?

After reviewing the results, I made several important improvements:

Moved secrets out of the codebase
Added token-based protection to secure sensitive routes
Removed sensitive fields such as card numbers and CVV from API responses
Cleaned up unsafe logging practices

Some fixes were applied automatically, while others required careful review and manual adjustments, which is expected when working with security-critical systems.

If you’re a developer who relies on AI to generate or automate parts of your code, tools like this become even more important. Cencori helps ensure that what gets produced isn’t just functional, but also secure. It acts as a safety layer, catching issues like exposed secrets, data leaks, and weak access controls before they make it into production.

In a world where speed is becoming easier with AI, security should not be an afterthought. Cencori helps you maintain that balance between building fast and building safely.

You can test it in your own project here:
https://cencori.com/

You can also explore the InsecurePay project here:
https://github.com/ladicodes/InsecurePay-API