# Nexus API: Why I'm Going Back to Native Node.js in the Age of AI > Source: > Published: 2026-09-15 13:03:02+00:00 AI has completely changed the way we build software. Today, I can describe a feature in natural language and, within seconds, have generated code, tests, an API structure, and even architectural suggestions. That's incredible. But there is a question I've been asking myself more and more: Are we becoming better programmers, or simply better at writing prompts? That question is one of the reasons I started building Nexus API. [🔗 Source code: GitHub Repository — Nexus API](https://github.com/dedaldinodev4/nexus-api) Nexus API is a personal laboratory where I'm exploring Node.js using mostly its native capabilities, without relying on frameworks to hide what happens underneath. The goal isn't to build the most sophisticated API in the world. The goal is to understand what is actually happening underneath the abstractions. The problem isn't using AI I'm not against AI tools. Quite the opposite. I use AI to explore ideas, compare solutions, find problems, automate repetitive tasks, and even learn new concepts. The problem starts when developers stop understanding what AI is producing. There is a huge difference between: "AI generated this code and it works." and: "I understand why this code works, what its limitations are, and how to change it when the requirements change." The first approach can produce fast results. The second produces better engineers. Nexus API Nexus API is a personal project I'm using as a laboratory to explore Node.js more deeply, relying heavily on Node's native capabilities instead of frameworks that abstract away much of the runtime. The goal is to understand what is actually happening underneath. I'm working primarily with native Node.js capabilities such as: → http → url → fs → path → crypto → events → stream → buffer → node:test → assert → process → Node's built-in modules → HTTP request/response → header parsing → routing → error handling → manual dependency injection → unit testing → integration testing → end-to-end testing Instead of simply writing: app.get('/users', controller.getAll) I want to understand what exists behind that abstraction. How does an HTTP request reach the process? How does Node represent request and response? How are headers processed? How is the request body received? How do streams work? How can we build routing without a framework? How should controllers, services, and repositories be separated? How can dependency injection be implemented without a container? How should each layer be tested? These questions are more valuable to me than simply getting an API running as quickly as possible. What I'm trying to learn The project forces me to deal with problems that are usually hidden behind frameworks. For example, I'm building an architecture similar to: src/ ├── modules/ │ └── users/ │ ├── users.routes.js │ ├── users.controller.js │ ├── users.service.js │ ├── users.repository.js │ └── users.test.js │ ├── core/ │ ├── http/ │ ├── errors/ │ └── middleware.js │ ├── app.js └── server.js It looks simple. And that's exactly the point. When you remove abstractions, you start noticing how many decisions a framework normally makes for you. HTTP stops being "magic" When using Express, Fastify, or NestJS, we can create a route in a few lines. That's great for productivity. But if we never learn what exists underneath those abstractions, we may eventually depend on them to solve problems that should be part of our foundation. In Nexus API, I'm exploring things like: const server = http.createServer((req, res) => { // routing // headers // body // authentication // controller // response }); Not because I want to replace Fastify or NestJS. I want to understand what these tools are doing for me. Once you understand the abstraction, using it becomes a conscious decision. Where does AI fit into this? This is the interesting part. I'm using AI while building the project. But I'm trying to reverse the relationship. Instead of: Prompt → code → copy → run I want: Concept → attempt → failure → investigation → implementation → AI as support Sometimes I implement something manually first. Then I ask AI to critique it. Other times, I ask for different approaches to a problem. Then I compare the solutions. I also use AI to generate test cases, find edge cases, and challenge architectural decisions. AI becomes a kind of pair programmer. Not the programmer. The danger of learning only through prompts There is a trend that concerns me. As AI tools become more powerful, some people are starting to question whether learning programming deeply is still worth it. The reasoning is: "If AI writes the code, why should I learn how to program?" I think the question is backwards. The more powerful AI becomes, the more important programming knowledge becomes. Someone still needs to evaluate the result. Someone needs to recognize when the solution is wrong. Someone needs to understand performance. Someone needs to identify a race condition. Someone needs to recognize a security problem. Someone needs to choose between a simple architecture and unnecessary complexity. Someone needs to understand trade-offs. And most importantly: someone needs to know what to ask for. A good prompt doesn't replace knowledge. Knowledge makes the prompt better. Fundamentals still matter Frameworks change. Libraries change. AI tools change. Models change. But some fundamentals remain. HTTP. TCP/IP. JavaScript. Runtime behavior. Memory. Processes. Streams. Concurrency. The event loop. Data structures. Algorithms. Databases. Distributed systems. Testing. Architecture. These concepts remain useful regardless of which tools we use. If a completely different framework appears tomorrow, the knowledge stays with us. Programming better, not just faster AI has made code generation extremely cheap. That changes the value of software development. Writing 500 lines of code is no longer necessarily an achievement. The challenge becomes knowing: which 500 lines should exist? Or even better: do we need those 500 lines at all? This is where fundamentals, experience, and reasoning become even more valuable. A strong developer isn't necessarily the person who writes the most code. It's the person who can solve complex problems with the minimum necessary complexity. The goal of Nexus API Ultimately, Nexus API is less about building an API and more about rebuilding my understanding of Node.js. I want to reach the point where, whenever I use a framework, I can think: "I know what this abstraction is doing underneath." That completely changes your relationship with the tool. You stop being dependent on it. You start choosing to use it. And that difference matters. AI + fundamentals I don't think we have to choose between learning programming and using AI. I believe in the opposite: Learn the fundamentals deeply and use AI to increase your capabilities. Use AI. Generate code. Automate tasks. Experiment. But also open the code. Read it. Break it. Test it. Reimplement it. Question it. And sometimes, turn off the abstraction and build something from scratch. That's exactly what I'm doing with Nexus API. Not to prove that frameworks are bad. But to understand what exists underneath them. And, most importantly, to remain a programmer — not just someone who knows how to ask AI for code. The project I'm keeping Nexus API on GitHub as an open learning laboratory for Node.js. The project will continue evolving as I explore: Node.js internals HTTP streams event loop architecture dependency injection testing performance security API design design patterns software engineering practices If you're also trying to deepen your Node.js fundamentals, feel free to follow the project, explore the code, or contribute. Code first. Abstractions second. AI as an accelerator — not a replacement for knowledge.