DEV Community: Ruslan Zholseitov

API — The New Ethical Frontier

Ruslan Zholseitov — Tue, 27 May 2025 12:46:53 +0000

Introduction

An API (Application Programming Interface) is a mechanism that allows two software components to interact using a set of definitions and protocols.
An API is like when someone walks you home and you invite them in "for a cup of tea." Everyone knows what that means. In Korea, it’s an invitation for ramyeon. In college, it's the tie on the doorknob.
An API is like an electrical outlet: a universal interface where various devices can connect.
An API is like crossing a border: you hand over your passport, the officer checks the photo, stamps it—everything works because both sides follow the same protocol.
These are unspoken, but clear protocols of interaction. If you're in the know, you understand. That's what an API is. It serves the same role for applications, helping them speak the same language.

Why APIs Without Standards Are a Problem

Now imagine you're invited to a traditional tea ceremony. Everything is graceful—the mat, the teacup, the precise gestures, aligned expectations. And then you suddenly start hugging the host. That's what an API without standards looks like. One side expects ritual, the other wants a fast-track to intimacy. The invitation was for "tea," the behavior—for something else. Without clear rules, the interaction turns into discomfort, mistrust, and digital violation.
It's like a traveler arriving in the U.S. with a European plug, unable to charge their laptop. Everything is seemingly connected, but the power doesn't flow. Integration breaks. Instead of seamless data exchange—disappointment. Even simple tasks become painful without compatible interfaces.
Now picture a border officer with no rules. You present your passport, and he asks you to show a lightsaber or sing in Sindarin. There’s no clarity, no protocol—just subjective demands. Crossing that border is scary: you never know what awaits behind the glass.
And it’s not just about inconvenience. Lack of standards undermines trust and transparency in the digital world. An API is essentially a contract between the provider and the consumer. By publishing an API, a company is promising: "This interface will behave predictably and won’t suddenly change."
But if every API says, "I return whatever I feel like," what trust can there be? Nobody wants to build integration on a sand foundation. Without transparency, suspicion arises that the API hides a black box or a trap.
Development culture also suffers. When anything goes, respect for users and industry norms disappears. The "as long as it works" mindset takes over—no care for who will use it, maintain it, or fix it when it breaks. That’s ethically unacceptable, especially in an age where technology pervades every part of life.

What’s Happening Now

Without a shared language and agreed-upon rules, the digital landscape is at risk of becoming a new Tower of Babel—a world where services can no longer understand one another.
We are entering a new era: APIs are now being designed by artificial intelligences. Experiments like qAPIx already exist—a concept of an assistant that builds APIs from scratch.
This AI asks the user for requirements, generates OpenAPI specs, suggests tests, and even drafts initial code. Such tools promise to become the norm: projects born faster with minimal human input. Sounds like a dream? There’s a flip side.
If we don’t embed ethical standards now, we face serious threats:
The Digital Tower of Babel — When every AI speaks its own dialect of API design, services become mutually unintelligible. Projects grow in isolation, infrastructures become incompatible, and integration grinds to a halt.
The API Cargo Cult — Without culture and understanding, AI will blindly copy existing patterns. Pseudo-"standards" emerge: magical templates devoid of meaning. Like tribes building wooden airplanes to summon cargo, developers will mimic APIs they don’t understand. The result: mountains of useless code.
The API Black Box — Handing over API creation to algorithms without oversight results in opaque services. From the outside, there’s an interface; inside, a mystery. No documentation, no design rationale. Such APIs are terrifying: bugs or backdoors may be buried deep, and nearly impossible to detect.
Uncontrolled Cloning — AI can generate an infinite number of APIs. Without ethical boundaries, it may replicate flawed designs or flood the world with slightly tweaked clones. Genuine innovation will drown in a sea of sameness.
These trends threaten to plunge the API ecosystem into chaos. Without structure and intentional design, APIs will devolve into data cannons—blasting out information to feed hungry AI models. Quality and planning will fall by the wayside. Even if APIs survive, using them will become unbearable.

What Should Be Done

To avoid digital chaos, we need a moral framework for APIs. At its core are standards and shared principles defined by the community. Specifications like OpenAPI provide a common language: clear to both humans and machines. Every endpoint, every parameter is transparently described—no ambiguity. These standards turn APIs into honest contracts: "Here’s what the service expects, here’s what it returns." This builds trust through clarity and consistency.
But ethical APIs aren’t just about specs. They’re about transparency, documentation, and thoughtful design. Anything that influences service behavior should be visible: to users, to developers. Great docs are a sign of respect. Good design is a gesture toward the future: APIs should be usable, secure, and sustainable—not a random shot in the dark.
AI must help build APIs—but on human terms. People remain architects, AI is the tool. We must train it not only in syntax, but in values. For example, qAPIx generates APIs from human instructions: producing OpenAPI specs, test cases, and structural consistency. It’s not a chaos engine, but a culture amplifier. It automates the grunt work within clear, meaningful boundaries.
In other words, the future of APIs must be governed. Humans define the rules, machines scale them. Together, we build infrastructure where speed and scale matter—but so do ethics, transparency, and trust.
New roles may emerge: guardians of API culture. People who ensure that amid rapid automation, we don’t lose the essentials: clarity, meaning, and respect for those who rely on these interfaces.

Conclusion

We stand at a new frontier: AI is already reshaping how APIs are made. The only question is what kind of world we want to build.
We can be careless—let algorithms raise a new Tower of Babel, where every system speaks its own incoherent dialect. Or we can consciously build a culture: lay down ethical standards, instill respect for interfaces as contracts, preserve transparency and trust.
The choice is ours. APIs are not just technical constructs. They reflect the values of their creators. The new ethical frontier is already here. The question is, will we cross it with integrity—armed with standards and conscience—or let technological chaos divide us?
The tower hasn't fallen yet. We still have a chance to guide the future. Let us be wise—for the sake of a shared digital culture.

How I Resurrected qAPIx and the Infrastructure Finally Came to Life

Ruslan Zholseitov — Tue, 27 May 2025 07:53:43 +0000

Sometimes, to move forward, you’ve got to throw everything out and rebuild from scratch. So that’s exactly what I did.

Tore the old qAPIx infrastructure apart, dumped the junk (frontend_old, you won't be missed), and carefully moved the living pieces — main.py, routers.py — into a clean new backend.
Found a couple of monsters: double app = FastAPI, redundant APIRouter()s — tamed and refactored them.

Launched docker-compose from scratch — no hacks, no ghost volumes. Got Mistral running locally, tunneled through ngrok, and finally — POST /chat worked across the entire stack.

Tested everything: Swagger → FastAPI → local Mistral → response. It flies (well... 3 minutes per reply isn’t exactly lightning, but it works).

Result:
qAPIx is alive.
The full chain GCP → ngrok → laptop → FastAPI → model is running like clockwork.
The project is ready to move forward. So am I.

How I Met Your Evaluation Strategy and Almost Shot Myself

Ruslan Zholseitov — Sun, 18 May 2025 09:23:15 +0000

It all started when I decided to run Mistral on my laptopй. Just the usual: scripts, datasets, terminal. But Mistral had other plans. I was expecting strings, but 75% of the data turned out to be lists. The model stared back at me like a cat being offered new food — complete confusion. I waved my hands, threw in more code, but nothing. Finally, I said to hell with the lists, let’s stick to dict. And things got better. For a while.
New round. Training still wasn’t working. evaluation_strategy="epoch"? Six hours wasted on one line! Turns out my version of TrainingArguments didn’t support half the parameters. Cut out everything unnecessary, left only the bare essentials. The model finally started responding. But not on the GPU. It was chugging along on the CPU. Cool, but while I was wrestling with those epochs, I forgot about the GPU.
Fine, I install accelerate. The terminal started spitting out error messages like a possessed printer. Apparently, pytorch and accelerate didn’t get along. Alright, we’re tough — fixed the versions, resolved conflicts. Now it should work, right? Wrong. Mistral in fp16 mode wanted 14 GiB of VRAM, and I only had 8. It’s like trying to park a truck in a basement. Okay, fine — let’s go 4-bit quantization.
Set up LoRA. r=8, alpha=32. Training started again. But then grad_norm suddenly turned into NaN. The model fell silent, like a lady who’s just been insulted. I dove back into the code. Turns out model.half() was breaking everything. Alright, ditch .half() and rerun. And finally, the long-awaited message: Houston, we have liftoff!
Numbers start flashing on the screen. train_loss — 2.14. Not bad for the first epoch. grad_norm was stable, learning_rate was gradually decreasing. I’m sitting there like a cat after a successful hunt — exhausted, but happy. GCP is resting, my laptop smells like it’s about to catch fire, and Mistral is finally alive.
And this is just the first chapter.

qapix #Mistral7B #MachineLearning #TrainingAI #DeepLearning #AIJourney #ModelTraining #DataScience #Debugging #GPU #LoRA #Quantization #CodingLife #GCP #TechDiaries #Programming #APIIntegration #LearningRate #DataPrep

How I Met Your Mistral and Tried to Train It...

Ruslan Zholseitov — Wed, 14 May 2025 10:11:24 +0000

Spun up a VM on e2-standard-8 (8 vCPU, 32 GB RAM), Ubuntu 22.04, 100 GB SSD. Neighboring servers started feeling jealous. Made a deal with myself: always shut down the VM or that $300 credit will vanish into the void.

Hooked up the Hugging Face token, loaded mistralai/Mistral-7B-v0.1. First run — no explosions, no drama. The model came to life and started talking in the terminal. I felt like Gandalf.

Set up train_lora.py, configured transformers, peft, datasets. First, some test data, then real API samples. The goal? Teach Mistral to speak API documentation fluently — endpoints, request models, auth, and all those tedious HTTP codes.

Downloaded 2701 specifications from APIs.guru, filtered out the junk — 2127 made it to the Golden Archive. Generated mistral_dataset.json with the key fields: endpoint, auth, request/response.

train: 1701 entries

val: 213 entries

test: 213 entries

GCP went down three times.

Conclusion: No GPU, no party. Off to find one.

How I Met CI/CD and Pretended to Be a DevOps for Two Days

Ruslan Zholseitov — Mon, 05 May 2025 12:52:31 +0000

(...and in two days I learned what CI/CD, buckets, and TailScale really are)

After qAPIx finally took shape — backend, frontend, everything neatly organized — I started wiring up the chat logic.
I designed and implemented the interaction like this:
AI asks → gets an answer → fills the block → moves on.
A simple mechanic — but the whole UX rests on it.

Then came the rest:
— Created a qAPIx-bucket in GCP to store artifacts
— Pushed everything to Git — no more keeping the project hostage in local zip archives

And finally, I decided the project had to be zen and properly managed:
✅ Created a GitHub repo
✅ Set up git pull/push from GCP using an SSH deploy key
✅ Installed Git directly on the VM
✅ The project now lives in Docker on GCP — stable and containerized

Then I tried to set up CI/CD.
It was a disaster, bro.
Spent a day and a half fighting to make it work: update the code → push → get a freshly deployed qAPIx with no fuss.

Connected Mistral and Starcoder:
— Mistral runs locally
— TailScale bridged it with GCP (yes, it’s a hack — but it works)
— Installed Ollama… and realized you can’t train models on it.
Another disaster, bro. Learned a lot, lost a few nerves.

But now qAPIx isn’t just a bunch of folders — it’s a living system with backups, pipelines, and AI.
Still… maybe I did something I’ll regret.
Why? I’ll tell you next time.

How I Met Your Frontend (and Almost Lost My Mind)

Ruslan Zholseitov — Fri, 02 May 2025 06:17:33 +0000

I kicked things off with a classic setup — Vite + React. Created the sacred folders: components, pages, api, utils. Hooked up Tailwind CSS, felt like a pro... but it didn’t work. After some debugging rituals, fixing tailwind.config.js, tweaking the content section, and upgrading Node.js to version 20 using n — it finally came to life. I felt like a CSS wizard.

Then came the UI. I built the holy trinity of QAPIX: QuestionCard, AnswerInput, and ProgressBar. Initially went with a “question–answer” form where the input disappears after submission. But hey, this isn’t 2010 — so I rewired it into a chat format. Now we’ve got a sleek messaging UI: you type, AI responds, everything’s neatly aligned and scrolls like a dream.

Next up was the logic. Our AI analyst asks questions, listens closely, digs deeper until it fills a logical block. Once that’s done — it either moves on or lets you choose what’s next. That’s the heart of QAPIX: a smart, chat-driven interrogation that’s oddly polite.

Now both frontend and backend are not just alive — they’re organized. FastAPI in the back, React + Tailwind in the front, everything structured and clean. Mistral API integration is next — it’ll handle question generation with brains. The project is growing, the frontend is alive. Time for coffee.

How I met your GCP and deployed the QAPIX Backend Knowing Nothing About GCP (and Leveled Up the Project in One Day)

Ruslan Zholseitov — Mon, 28 Apr 2025 04:12:59 +0000

I spent a long time debating where to host the project. On my local machine—something felt off. I started comparing server rentals and narrowed it down to Google and Yandex. Yandex was cheaper, but I trusted Google more.
So I sat down to deploy QAPIX on Google Cloud Platform. Until then, my exposure to GCP had been limited to screenshots online.
I spun up an Ubuntu VM—and off we went. Docker, Docker Compose—all by hand, without any scripts or templates. Networking? VPC in a minute, but I didn’t immediately grasp why the firewall on ports 80 and 8080 wouldn’t respond to pings.
Containers gave me freedom:
PostgreSQL (postgres:15): packed into its own service, attached a volume to a Persistent Disk, initialized the database.

FastAPI on Python 3.11 with Uvicorn: connected to the DB via asyncpg, and Swagger UI kicked in “out of the box.”

Nginx: routed traffic from port 80 to 8080 so as not to break the frontend.

I didn’t sweat the DB schema—I’ve got enough experience—so I modeled everything in Pydantic in half an hour. Another hour went into CRUD endpoints. One typo in a route—and everything crashed.
I fell in love with testing via Swagger immediately: two clicks and you see the JSON flying. And my trusty Postman collections, with assertions on status codes and payload structures, saved me from endless “404” loops.
So, knowing almost nothing about Docker, Nginx, or Python (those few levels I did in Mimo don’t really count), I managed to deploy the backend for our future system using only advice and scripts from ChatGPT.
I’ll abandon it all later, but why—that’s a tale for another time.

SystemAnalysis #APIDesign #AIinTech #OpenAPI #Microservices #DigitalTransformation #ProductIdea #TechLeadership #ChatGPT #StartupJourney #QAPIX #Innovation #DeveloperTools #APIAutomation #AIforDevelopers #IntegrationArchitecture

How I met your System Analysis and became a Systems Analyst without knowing anything about system analysis

Ruslan Zholseitov — Thu, 24 Apr 2025 10:47:51 +0000

(And came up with an idea that might change the game)
Last year, I joined a new company — right into the fire. The task? Migrate a monolithic system to microservices. My domain was the integration bus.
There was just one problem: my skills as a Systems Analyst were close to zero. I had some background as a Business Analyst, but this was another level — designing APIs, thinking through architecture, documenting risks, errors, and interaction schemes. I was completely unprepared.
But I had one advantage: years of experience as a Project Manager and the ability to negotiate. So I made a deal with leadership — if our ESB team delivered 8 services per month, we’d get bonuses. If not — just the base salary.
Challenge accepted. I dove into system analysis. A senior analyst onboarded me and helped a lot, but I quickly realized he didn’t have time to teach me everything. That’s when I turned to the one who always had time: ChatGPT.
I started asking it 100+ questions a day. What should an endpoint look like? How to handle errors? What about timeouts? What’s the best method for this use case? A real person would’ve gone mad. But ChatGPT delivered — clear, structured answers that worked in practice.
Before long, services started rolling out. The team stopped looking at me like I didn’t belong. Things were working.
And then I paused and had a realization:
Who was really doing all this?
The endpoints? ChatGPT.
The architecture? ChatGPT.
The error handling, data structures, logic — all generated by AI.
I was more of a translator than a creator.
And that’s when the idea hit me:
What if this entire process could be automated?
If an AI could handle 80% of the system analyst’s work — why not build a tool for it?
That’s how the idea of QAPIX was born — a smart assistant that helps design APIs end-to-end:

It asks the right questions
Generates OpenAPI specs
Suggests test cases
Creates starter code
Integrates with GitHub and Jira

QAPIX doesn’t exist yet. But the idea is alive.
If you believe system analysis can be automated — follow the journey.
It’s going to be exciting.