DEV Community: restu ananda saputra

API Gateways Are More Than Just a Reverse Proxy

restu ananda saputra — Fri, 31 Jul 2026 16:38:18 +0000

When developers first learn about microservices, the architecture often looks straightforward. Each service exposes its own API, and clients communicate directly with whichever service they need. It works well at a small scale, but as the number of services grows, that simplicity quickly disappears.

This is where an API Gateway becomes one of the most valuable pieces of the architecture. Instead of exposing dozens of backend services to the outside world, an API Gateway provides a single entry point that receives every request and forwards it to the appropriate service. To the client, there's only one API. Behind the scenes, the gateway handles the complexity.

What makes an API Gateway powerful isn't just request routing. It centralizes many cross-cutting concerns that every distributed system eventually needs. Authentication and authorization can be enforced consistently. Rate limiting helps prevent abuse and protects backend services from traffic spikes. Caching reduces unnecessary requests and improves response times. Logging, monitoring, and request transformation can all be managed in one place instead of being duplicated across every microservice.

This separation allows development teams to focus each service on solving business problems rather than repeatedly implementing the same infrastructure concerns. It also makes the overall system easier to maintain because changes to security policies or traffic management can often be made at the gateway without modifying every application.

There isn't a single solution that fits every project. Self-hosted options like YARP, Ocelot, Traefik, and Envoy are popular choices depending on your technology stack and operational requirements. If you're already building in the cloud, managed services such as Azure API Management or Amazon API Gateway can significantly reduce the operational overhead of running gateway infrastructure yourself.

I've found that many teams initially think of an API Gateway as simply another reverse proxy. In reality, it's often the front door of the entire platform. The decisions made there—around security, observability, performance, and traffic management—can have a much bigger impact on the reliability of a distributed system than the routing itself.

If you're building microservices today, would you choose a self-hosted API Gateway like Envoy or Traefik, or would you rather rely on a managed cloud solution?

🚀 Need help building scalable web applications, APIs, or distributed systems?

Contra:

Restu ananda saputra - AI Agent Engineer | Contra

Web Developer creating complex task. View Restu ananda saputra's Profile on Contra. The Independent-first, commission-free freelance marketplace shaping the future of work.

contra.com

Fastwork:

Restu ananda saputra (@restuanand) | Fastwork Indonesia

Restu ananda saputra | Rating pengguna 0,0 bintang, dipekerjakan 0 kali. Layanan berkualitas dari Restu ananda saputra, freelancer profesional di Fastwork Indonesia — pekerjakan dengan penawaran terbaik!

fastwork.id

Upwork:

upwork.com

API #Microservices #SoftwareArchitecture #SystemDesign #BackendDevelopment #CloudComputing #DevOps #YARP #Envoy #Traefik

The Biggest Payment Mistake Isn't Choosing the Wrong Gateway. It's Designing Your System Around One.

restu ananda saputra — Sun, 26 Jul 2026 11:28:24 +0000

When a team starts building a product that needs online payments, one discussion almost always comes up before any architecture diagrams are drawn or code is written.

Which payment gateway should we use?

Depending on where you're building, the shortlist usually looks familiar. Stripe, Xendit, Midtrans, DOKU, Adyen, PayPal, Braintree, or perhaps a regional provider that dominates the local market. The comparison spreadsheet quickly fills with transaction fees, supported payment methods, settlement times, dashboard features, API documentation, and reliability metrics.

At first glance, it feels like one of the most important architectural decisions you'll make.

But after working on systems that process payments, I've come to think the question itself is slightly wrong.

The real challenge isn't choosing the best payment gateway.

It's making sure your application doesn't become dependent on whichever provider you happen to choose first.

There Is No Perfect Payment Gateway

Every payment provider has strengths, and every provider has limitations.

Some offer excellent support for international credit cards but have limited local payment methods. Others dominate domestic bank transfers yet provide weaker cross-border capabilities. One platform might have outstanding API documentation, while another offers lower transaction fees or faster settlement periods.

Even the largest providers in the industry experience occasional outages, scheduled maintenance, degraded performance, or temporary service interruptions.

That's simply the reality of distributed systems.

No matter how much research you do before launch, there will eventually be a situation where another gateway becomes a better fit for part of your business.

The problem begins when your software isn't prepared for that change.

The Hidden Cost of Tight Coupling

Imagine your application is integrated directly with a single payment gateway.

Your checkout flow calls the provider's SDK.

Your order service stores the provider's transaction IDs.

Your webhook handler understands only one event format.

Your refund logic depends entirely on one API.

At first, everything feels simple.

Until one day it isn't.

Perhaps your biggest marketing campaign begins, and the provider experiences an unexpected outage. Customers can't complete purchases, shopping carts are abandoned, and revenue stops flowing.

Or maybe your company expands into another country where your existing gateway doesn't support the payment methods customers actually use.

Now what seemed like a straightforward integration suddenly becomes a major engineering project.

Instead of adding another payment provider, you're forced to untangle payment logic that's spread across controllers, services, databases, webhook handlers, notification systems, and reporting pipelines.

Changing providers becomes less like swapping a component and more like performing open-heart surgery on a production system.

Thinking in Terms of Architecture, Not Vendors

One lesson I've learned is that mature systems rarely allow business logic to communicate directly with external providers.

Instead, they introduce an abstraction layer.

Rather than asking Stripe to create a payment, or calling Midtrans directly from the checkout service, the application communicates with its own internal payment interface.

Conceptually, the interaction becomes much simpler.

Application
      │
      ▼
Payment Service
      │
      ▼
Payment Abstraction Layer
      │
 ┌────┴─────────────┐
 ▼                  ▼
Stripe         Xendit
 ▼                  ▼
Midtrans        Adyen

From the application's perspective, the request never changes.

Create Payment

Amount: $250
Currency: USD
Payment Method: Credit Card
Customer: #12458

How that payment is ultimately processed becomes an implementation detail hidden behind the abstraction.

Routing Payments Intelligently

Once an abstraction layer exists, routing logic becomes incredibly flexible.

Instead of hardcoding one provider, the system can decide dynamically.

For example:

IF payment_method == Credit Card
    → Stripe

ELSE IF payment_method == Virtual Account
    → Xendit

ELSE IF country == Indonesia
    → Midtrans

ELSE
    → Adyen

That routing logic can become even more sophisticated.

You might choose providers based on:

Customer location
Currency
Transaction value
Provider availability
Processing fees
Historical success rates
Preferred payment method
Regulatory requirements

The business logic never needs to know which provider ultimately handles the payment.

It simply asks for a successful transaction.

High Availability Through Failover

One of the biggest advantages of this architecture is resilience.

Suppose your primary provider becomes unavailable.

Without an abstraction layer:

Checkout
      │
      ▼
Stripe ❌
      │
      ▼
Payment Failed

With intelligent routing:

Checkout
      │
      ▼
Stripe ❌
      │
Retry
      ▼
Adyen ✅
      │
Payment Success

To the customer, the transaction succeeds.

Many users never realize a failover occurred.

That's exactly how resilient systems should behave.

Designing a Payment Interface

A clean abstraction often begins with a simple contract.

Instead of exposing provider-specific APIs throughout the application, define a common interface.

interface PaymentGateway {
    createPayment(request)
    capturePayment(id)
    refundPayment(id)
    cancelPayment(id)
    getPaymentStatus(id)
}

Each provider then implements the same behavior.

StripeGateway

implements PaymentGateway

MidtransGateway

implements PaymentGateway

XenditGateway

implements PaymentGateway

The rest of the application interacts only with the interface.

Changing providers no longer requires changing business logic.

Supporting Future Growth

Another benefit often overlooked is expansion.

Imagine your company launches in Indonesia.

Midtrans works perfectly.

A year later, you expand into Singapore.

Then Australia.

Then Europe.

Each region has different customer expectations.

Some prefer credit cards.

Others use bank transfers.

Some rely on digital wallets.

Others expect Buy Now, Pay Later (BNPL) services.

If your architecture assumes a single payment provider forever, international expansion becomes increasingly difficult.

If your payment layer was designed for multiple providers from the beginning, adding support for another market becomes significantly easier.

You're extending the platform rather than rebuilding it.

Vendor Lock-In Is an Architectural Problem

Vendor lock-in isn't unique to payment gateways.

It happens with cloud providers.

Databases.

Authentication systems.

Message queues.

Search engines.

Storage platforms.

The more tightly your business logic depends on a specific implementation, the harder migration becomes later.

Good architecture isn't about predicting which technology you'll use forever.

It's about assuming change is inevitable.

Abstraction is one of the most effective ways to prepare for that reality.

But Should Every Startup Build This?

Not necessarily.

One mistake engineers sometimes make is overengineering too early.

If you're building an MVP with limited traffic, integrating directly with a single payment gateway is often the right decision.

Shipping a product usually creates more value than designing a perfect architecture that never reaches production.

The key is recognizing when the investment becomes worthwhile.

As transaction volume grows...

As multiple payment methods become necessary...

As expansion into new markets becomes realistic...

As uptime becomes business-critical...

That's when introducing a payment abstraction layer starts paying for itself.

Architecture should evolve alongside the business.

Final Thoughts

When people discuss payment systems, the conversation usually centers on providers.

Which gateway has the lowest fees?

Which dashboard looks better?

Which API is easier to integrate?

Those questions matter.

But they're rarely the most important ones.

The more valuable question is this:

If we needed to replace this provider next year, how much of our application would need to change?

If the answer is "almost everything," then the architecture—not the payment gateway—is probably the real problem.

Sometimes the smartest engineering decision isn't choosing the perfect technology.

It's designing your system so that replacing technology is never a crisis.

That's the kind of flexibility good architecture gives you.

And in software engineering, flexibility often turns out to be one of the most valuable features you can build.

Thanks for Reading

If you enjoy articles about software architecture, backend engineering, scalable systems, AI engineering, cloud computing, and modern application design, feel free to follow my work. I enjoy sharing practical lessons from real-world software development, architectural decisions, and the engineering trade-offs that rarely make it into official documentation.

Outside of writing, I work with founders, startups, and businesses to design and build scalable software solutions—from payment systems and backend platforms to AI-powered applications, automation tools, and cloud-native architectures. If you're building something interesting and need a software engineer to help bring it to life, I'd be happy to connect.

I’ve always enjoyed sharing what I learn, whether it’s from building software, exploring new technologies, participating in research projects, or simply solving problems that took longer than expected. Writing became a natural extension of that process.

Most of my work revolves around software engineering, cloud technologies, system design, artificial intelligence, and digital product development. Over the years, I’ve worked on a variety of projects, from business applications and websites to more technical topics involving architecture, scalability, and emerging technologies. Many of my articles are inspired by real experiences, lessons learned, mistakes made, and observations from working in technology.

What I enjoy most about writing is the opportunity to make complex ideas easier to understand. Some people discover new concepts through books, others through videos. For me, writing is how I explore topics more deeply while hopefully helping others learn something useful along the way.

Joining the Medium Partner Program feels like a natural next step. I plan to continue publishing articles about technology, software engineering, artificial intelligence, personal growth, and the challenges of building products in an increasingly digital world. My goal is not only to share information but also to contribute thoughtful perspectives that readers can apply to their own work, careers, and projects.

🚀 Need help building AI-powered applications, scalable software, mobile apps, web scraping, or business automation?

Contra:

Restu ananda saputra - AI Agent Engineer | Contra

Web Developer creating complex task. View Restu ananda saputra's Profile on Contra. The Independent-first, commission-free freelance marketplace shaping the future of work.

contra.com

Fastwork:

AI Workflow Automation & System Integration —…

Modern businesses rely on dozens of applications to manage sales, customer support, operations, finance, marketing, and internal communication. As…

fastwork.id

Upwork:

upwork.com

💬 If you were designing a payment platform today, would you integrate directly with one gateway or build an abstraction layer from day one?

SoftwareEngineering #SystemDesign #SoftwareArchitecture #BackendDevelopment #Payments #FinTech #Programming #Developers #ScalableSystems #Technology

Designing Software for AI Agents: Why Agent Experience (AX) May Become the Next Competitive Advantage

restu ananda saputra — Mon, 20 Jul 2026 12:20:39 +0000

A few years ago, if someone had asked me who I was building software for, my answer would have been straightforward. I build software for users. If the product exposed an API or SDK, then I also built it for developers. That was the relationship we had with software for decades. Users interacted with interfaces, developers integrated systems, and engineering teams focused on making both experiences as seamless as possible.

Today, I don't think that answer is complete anymore.

Over the past year, I've noticed something quietly changing across the software industry. More and more products are no longer being used exclusively by people. Increasingly, they're being consumed by AI. Sometimes it's an AI coding assistant reading your documentation before another engineer opens it. Sometimes it's an autonomous workflow deciding whether your API is reliable enough to integrate. Other times it's a browser agent navigating your application to complete repetitive business tasks without anyone clicking through the interface manually.

It's an interesting shift because it introduces a new audience that most of us never consciously designed for. We spent years refining User Experience (UX) to help people accomplish tasks more easily, and we invested heavily in Developer Experience (DX) so engineers could build integrations with minimal friction. Now there is a third audience entering the conversation, and unlike the other two, it doesn't care how beautiful your interface looks or how polished your landing page feels. It only cares whether your software is understandable, predictable, and trustworthy.

That's why I believe we'll hear a lot more about Agent Experience (AX) over the next few years.

Software Has Quietly Gained a New User

When we talk about AI, most discussions revolve around models becoming larger, smarter, or faster. We compare benchmark scores, reasoning capabilities, context windows, and coding performance. Those conversations are important, but they often overlook something happening underneath.

AI is gradually becoming another consumer of software.

Think about how many development workflows already involve AI today. GitHub Copilot suggests implementations by reading the surrounding codebase. Claude Code explores repositories to understand project architecture before making changes. Cursor indexes documentation and source code so it can answer implementation questions. Autonomous agents built with frameworks like LangGraph or Model Context Protocol (MCP) inspect APIs, execute tools, and make decisions without direct human involvement.

In each of those situations, your software is no longer communicating only with people.

It's communicating with another piece of software that happens to reason using language.

That changes the way we should think about designing modern systems.

AI Doesn't Experience Software the Way Humans Do

One of the easiest mistakes to make is assuming AI evaluates software the same way people do.

Humans naturally appreciate thoughtful interfaces. We notice typography, spacing, animations, colors, branding, and visual consistency. Developers tend to evaluate products differently. They look for good documentation, clear authentication flows, helpful SDKs, and examples that make integration straightforward.

AI evaluates software through an entirely different lens.

It doesn't care whether your homepage has impressive animations. It doesn't care whether your buttons follow the latest design trends. It isn't impressed by gradients or polished illustrations.

Instead, it asks questions that sound much more like this:

Can I discover every available endpoint?
Are response objects consistent?
Is authentication clearly documented?
Can I understand this error automatically?
Is this operation deterministic?
Can I safely retry this request?

Those questions aren't about aesthetics.

They're about certainty.

The easier your software is to understand programmatically, the more valuable it becomes to AI systems that need to reason about it.

Predictability Is Becoming More Valuable Than Cleverness

Over the years I've reviewed many APIs that technically worked but felt unnecessarily difficult to understand. Often the problem wasn't performance or functionality. It was inconsistency.

Consider two different approaches.

The first API might expose endpoints like:

/getUser
/allUsers
/createUser
/deleteUser

Nothing is fundamentally broken.

Now compare that with an API following predictable REST conventions:

GET /users
GET /users/{id}
POST /users
PUT /users/{id}
DELETE /users/{id}

Both APIs solve the same problem.

The difference is that the second communicates intent much more clearly.

Humans appreciate consistency because it reduces cognitive load. AI depends on consistency because patterns are how it generalizes behavior. Once an agent understands one endpoint, it can often infer how the rest of the API behaves without additional explanation.

Predictability becomes a feature in its own right.

Documentation Is No Longer Just for Humans

Documentation has traditionally been something teams finished after shipping the product. Sometimes it was treated almost like a formality.

I don't think that's true anymore.

Documentation is increasingly becoming part of the interface itself.

When an AI assistant generates integration code, it doesn't magically know how your platform works. It reads your documentation, examines schemas, studies examples, and builds an internal understanding of your system before writing a single line of code.

Every missing example creates uncertainty.

Every undocumented endpoint increases ambiguity.

Every inconsistent explanation makes automated reasoning more difficult.

That's one reason standards like OpenAPI, JSON Schema, AsyncAPI, and MCP are becoming increasingly important. They don't simply document software for people. They describe software in a structured way that machines can understand as well.

The better those descriptions become, the less time both developers and AI spend making assumptions.

Error Messages Are Becoming Part of the Conversation

One area I think many teams still underestimate is error handling.

For humans, an error message is often just feedback explaining what went wrong.

For AI, an error message is an opportunity to recover automatically.

There's a significant difference between returning:

"Invalid request."

and returning structured information explaining which field failed, why it failed, and what correction should be made.

That additional context transforms an error from a dead end into another decision point.

Instead of giving up, an AI agent can retry with corrected input, ask for clarification, or choose a different execution path entirely.

Good error messages no longer improve only the developer experience.

They improve the agent experience too.

Building Software That Machines Can Trust

The more I think about Agent Experience, the more I realize it isn't introducing completely new engineering principles.

Instead, it's reinforcing principles we've known for years.

Predictable APIs.

Consistent naming conventions.

Clear authentication.

Stable versioning.

Structured documentation.

Meaningful error responses.

Deterministic behavior.

Explicit business rules.

These practices have always resulted in better software.

The difference now is that AI exposes weaknesses much faster than people do. Humans often work around inconsistencies through intuition or experience. Machines can't. They rely on clear contracts, structured information, and repeatable behavior.

Ironically, designing software that AI understands often results in software that humans appreciate even more.

Why I Think This Matters More Than the Next AI Model

Many organizations are currently focused on choosing the best AI model.

Should they use GPT?

Claude?

Gemini?

Open-source alternatives?

Those decisions certainly matter.

But I suspect they'll become less important over time.

The larger competitive advantage won't come from having access to a particular model.

It will come from how well your engineering organization teaches that model to understand your systems.

Companies with predictable architectures, excellent documentation, structured APIs, and well-defined engineering standards will allow AI to become productive almost immediately.

Companies with fragmented documentation, inconsistent conventions, and undocumented business logic will continue forcing every AI assistant to rediscover the same information over and over again.

Eventually the model won't be the bottleneck.

The quality of the software ecosystem surrounding it will.

Final Thoughts

For decades, software engineering has focused on building products that people enjoy using and developers enjoy building on.

That foundation isn't changing.

What is changing is the audience.

Software increasingly communicates with other software that can reason, plan, automate, and make decisions on behalf of people. As that trend continues, products won't simply compete based on features or interface design. They'll also compete on how easily intelligent systems can understand, trust, and integrate them into larger workflows.

Perhaps that's the most interesting part of this shift.

Agent Experience isn't replacing User Experience or Developer Experience.

It's becoming the bridge between them.

The companies that recognize this early won't just build products that people love using.

They'll build products that AI understands naturally, integrates confidently, and chooses automatically.

I have a feeling that will become one of the defining characteristics of great software over the next decade.

Thanks for Reading

If you enjoy reading about software engineering, system architecture, AI engineering, backend development, cloud computing, and building scalable digital products, you're in the right place. I regularly share practical lessons, engineering insights, and reflections from projects I've worked on, along with ideas that I believe will shape the future of modern software development.

Beyond writing, I work with founders, startups, businesses, researchers, and organizations to design and build scalable software solutions. Whether it's developing AI-powered applications, architecting cloud infrastructure, modernizing legacy platforms, building custom business systems, or turning a product idea into production-ready software, I genuinely enjoy solving complex engineering problems.

I'm also happy to support educational initiatives, open-source communities, research collaborations, and non-profit projects whenever I can. If you're building something meaningful and think I can help, feel free to reach out. I'd always enjoy connecting with people who are passionate about building technology that creates real impact.

Microsoft's 99 AI Skills Are Interesting. The Bigger Story Is What They Represent.

restu ananda saputra — Thu, 02 Jul 2026 17:36:46 +0000

AI coding assistants already understand .NET. The next challenge is teaching them how your team builds software.

One of the most interesting things happening in software engineering right now isn't the arrival of another language model.

It's the gradual realization that intelligence alone isn't enough.

Over the past couple of years, AI coding assistants have become remarkably capable. Whether you're using GitHub Copilot, Claude Code, Cursor, Codex, or another modern coding assistant, it's difficult not to be impressed by how quickly they can generate APIs, write unit tests, explain unfamiliar code, or scaffold entire applications.

In many cases, they already understand programming languages better than most developers ever will.

Ask them about C#, ASP.NET Core, Entity Framework, LINQ, Minimal APIs, dependency injection, or asynchronous programming, and the answers are usually accurate, well-structured, and surprisingly practical.

Yet despite all of that progress, I continue hearing the same complaint from engineering teams.

"The AI still doesn't understand our project."

At first, that sounds like a limitation of the model itself.

The more I think about it, the more I believe it's actually a limitation of context.

Understanding a Language Isn't the Same as Understanding a Codebase

Knowing how .NET works is only one small part of software engineering.

Every engineering organization develops its own way of building software.

Some teams organize their applications around Clean Architecture.

Others prefer Vertical Slice Architecture.

Some rely heavily on CQRS with MediatR.

Others use repository patterns, Result, domain events, feature folders, or entirely custom conventions that have evolved over years of development.

Then there are the business rules.

The naming conventions.

The deployment pipeline.

The testing philosophy.

The internal libraries.

The security requirements.

The architectural decisions that exist nowhere except inside the heads of experienced engineers.

This is the context that makes one company's codebase fundamentally different from another's.

Modern language models understand C#.

What they don't automatically understand is your organization.

Every new conversation begins from almost zero.

The assistant has to rediscover your architecture, infer your conventions, and guess how your team prefers to solve problems.

That's an incredibly expensive way to collaborate.

Why Microsoft's Repository Matters

This is why Microsoft's recently open-sourced dotnet/skills repository caught my attention.

At first glance, the announcement appears relatively straightforward.

Microsoft published nearly one hundred reusable AI skills covering common .NET development tasks such as ASP.NET Core, Entity Framework, testing, project modernization, upgrades, and AI application development.

For many developers, the headline became the number.

Ninety-nine skills.

An impressive collection.

But I think the number is the least interesting part.

The real innovation is the idea behind it.

Instead of repeatedly explaining the same workflows every time an AI assistant starts a new session, those instructions can be packaged into reusable skills that compatible AI agents automatically load whenever they're relevant.

The assistant doesn't need to be reminded how to approach a particular .NET task.

The knowledge already exists.

The context is reusable.

Microsoft Can Teach AI About .NET

Only You Can Teach AI About Your Company

This is where I think the conversation becomes much more interesting.

Microsoft can teach AI how to write better .NET applications.

Only your engineering team can teach AI how to build software your way.

Imagine every architectural principle your team follows becoming reusable knowledge.

Your preferred folder structure.

Your API design guidelines.

Your naming conventions.

How authentication works.

How repositories are organized.

How pull requests should be reviewed.

How services communicate.

How logging is implemented.

How feature flags are introduced.

How migrations are managed.

How domain models evolve.

Instead of explaining these ideas repeatedly, they become part of your organization's shared engineering memory.

Every AI-assisted development session starts with context rather than assumptions.

That changes the relationship between engineers and AI completely.

From Prompts to Organizational Knowledge

One pattern has become increasingly obvious over the last year.

Most developers spend far too much time repeating themselves.

Every prompt includes reminders about coding standards.

Every conversation explains the same architecture.

Every new feature starts with another description of how the application is structured.

Eventually, prompt engineering becomes organizational overhead.

Reusable skills solve a different problem.

Instead of writing better prompts, teams begin capturing institutional knowledge.

Knowledge stops living inside Slack conversations, onboarding documents, or the minds of senior engineers.

It becomes something AI can actively use while generating software.

That may sound like a subtle difference.

I don't think it is.

It's the difference between asking someone to remember instructions every day and giving them a well-designed handbook they can reference automatically.

The Competitive Advantage Is Shifting

When AI coding assistants first became popular, much of the conversation focused on choosing the best model.

Should you use Claude?

Copilot?

Cursor?

Codex?

The assumption was that better models would naturally create better engineering outcomes.

I'm no longer convinced that's where the biggest advantage will come from.

As foundation models continue improving, the performance gap between them will likely become smaller.

What becomes difficult to copy isn't the model.

It's the organizational knowledge surrounding it.

Every engineering team has accumulated years of architectural decisions, operational experience, coding conventions, business rules, deployment strategies, and technical trade-offs.

That knowledge is incredibly valuable.

Until recently, most of it existed only inside documentation or experienced engineers.

Now it can become something AI actively participates in.

That's a much more durable competitive advantage than simply paying for access to the latest language model.

Software Engineering Is Becoming More About Context

The longer I work with AI-assisted development, the more I believe that software engineering is quietly shifting from writing code toward managing context.

Generating code is becoming cheaper every month.

Providing the right context is becoming increasingly valuable.

The organizations that succeed won't necessarily be the ones with the most advanced AI models.

They'll be the ones that systematically teach those models how they build software, why they make certain architectural decisions, and what quality means inside their engineering culture.

That's knowledge no foundation model can learn on its own.

Conclusion

Microsoft's ninety-nine AI skills are undoubtedly useful.

They'll help developers work more effectively with .NET, automate common tasks, and reduce repetitive instructions during AI-assisted development.

But I think the repository points toward something much bigger.

The future isn't simply AI that understands programming languages.

It's AI that understands engineering organizations.

Because once an assistant understands not only how to write C#, but also how your team designs systems, reviews code, structures projects, and makes architectural decisions, something fundamental changes.

The assistant stops feeling like a code generator.

It starts feeling like a new engineer who's already completed onboarding.

And that may become one of the most valuable productivity improvements software engineering has seen in years.

Building AI-Powered Software

I spend much of my time helping founders, startups, and businesses build modern software systems, integrate AI into existing products, and design cloud-native architectures that can scale as businesses grow.

If you're exploring AI-assisted development, custom business software, intelligent automation, or scalable web applications, I'd be happy to help turn those ideas into production-ready solutions.

Fastwork: https://fastwork.id/byob/7pFhYwWqZd?openExternalBrowser=1&source=byob

Upwork: https://www.upwork.com/services/product/development-it-custom-business-website-development-2067932090568948507?ref=project_share

About Me

Most days you'll find me building software, experimenting with AI, exploring distributed systems, and writing about the ideas I encounter along the way.

I'm particularly interested in software engineering, artificial intelligence, cloud computing, system architecture, and how emerging technologies are changing the way we design, build, and maintain software. Through these articles, I share lessons from real projects, technical research, and observations about where our industry is heading.

I don't write because I think I have all the answers. I write because some of the best ideas emerge when they're shared, challenged, and refined together.

I Wish I Had Started Documenting My Tech Journey Earlier

restu ananda saputra — Sat, 27 Jun 2026 17:49:25 +0000

The biggest thing I lost wasn't code—it was the story of how I became an engineer.

If I could go back and give my younger self a single piece of advice, it probably wouldn't be to learn another programming language, contribute to open source earlier, or spend more time studying algorithms.

Those things certainly matter, and they've all helped shape my career in one way or another.

But looking back, none of them feel like the advice I needed most.

Instead, I would tell myself something much simpler.

Document the journey.

When I first started programming, I believed the important things would naturally stay with me. I assumed I would always remember the excitement of finishing my first real application, the nights spent chasing bugs that made absolutely no sense, the satisfaction of finally seeing a project come together, and the countless small lessons that slowly transformed me from someone who simply wrote code into someone who started thinking like an engineer.

I couldn't have been more wrong.

Time has an interesting way of preserving the highlights while quietly erasing everything in between. Years later, I can still remember the names of projects I built and the companies I worked with, but many of the moments that actually changed me have become blurry. I struggle to remember what I was thinking when I faced certain problems, what made me nervous before launching something for the first time, or why solving a seemingly simple bug once felt like such a huge accomplishment.

The milestones remained.

The journey slowly disappeared.

Waiting Until I Felt "Qualified"

Looking back, I don't think I avoided writing because I was too busy.

Like most developers, I could always find a few minutes to write a note, publish a short article, or record what I had learned that week. The real reason was much more subtle.

I convinced myself that I wasn't experienced enough.

Every time I considered writing about something I had learned, another voice would immediately appear in my head.

Who would want to read advice from someone who's still learning?

So I kept postponing it.

I told myself I would start documenting once I became a better engineer. Maybe after building larger systems. Maybe after getting more professional experience. Maybe after I had earned the confidence to call myself an expert.

The problem with that mindset is that every new milestone simply creates another reason to wait.

When I learned a new framework, I felt there was still another one I should master first.

When I finished one project, I believed the next one would be more impressive.

When I gained more experience, my standards for sharing became even higher.

The finish line kept moving.

And because it kept moving, the "right time" never actually arrived.

The Version of Me I'll Never Meet Again

Ironically, the version of myself I most wish I could revisit isn't the engineer I am today.

It's the beginner.

The person who approached every technology with endless curiosity, celebrated solving problems that now seem trivial, and experienced genuine excitement every time a new concept finally clicked.

Those early days were filled with questions.

Every project introduced something I had never seen before.

Every mistake taught me something valuable.

Every success felt enormous because everything was new.

Unfortunately, those memories exist mostly in fragments now.

I remember that they happened.

I just don't remember them as clearly as I wish I did.

Sometimes I wish I could open a notebook written by my younger self and read what I was thinking during those first months of learning.

What confused me?

What inspired me?

What challenges seemed impossible at the time?

Those questions no longer have complete answers because I never took the time to write them down.

Why I Admire Developers Who Learn in Public

One thing I genuinely admire today is seeing students and junior developers openly share what they're learning.

They publish small projects.

They write about bugs they solved.

They explain concepts they only recently understood.

They celebrate milestones that more experienced engineers might overlook.

Years ago, I probably would have thought they were sharing too early.

Today, I think they're doing something incredibly valuable.

They're preserving a version of themselves that will eventually disappear.

Five years from now, those posts won't simply be technical content.

They'll become a timeline of personal growth.

A record of mistakes.

A collection of breakthroughs.

Proof that they kept moving forward even when progress felt painfully slow.

In many ways, they're writing something for their future selves just as much as they're writing for everyone else.

Documentation Is More Than a Personal Brand

One of the biggest misconceptions about documenting your work is that it's only useful if you're trying to build an audience.

People often associate writing with personal branding, networking, or attracting recruiters.

Those are certainly worthwhile outcomes.

I've seen firsthand how sharing knowledge can open unexpected doors.

But I don't think those are the most meaningful reasons to document your journey.

The greatest value is much more personal.

Documentation preserves growth.

A GitHub repository isn't simply a collection of source code.

It's evidence that you kept building.

A technical article isn't just something published on the internet.

It's a snapshot of what fascinated you at a particular point in your career.

Even a short LinkedIn post becomes more than an update after enough time has passed.

It becomes a reminder of where your thinking was, what problems you were solving, and who you were becoming.

Progress is surprisingly difficult to notice while you're living through it.

Documentation allows you to see it years later.

The Story Is Still Being Written

One realization has become increasingly comforting to me.

It's never too late to begin.

None of us can go back and document yesterday.

The early projects that were never recorded will probably remain memories, and some of those memories will continue fading with time.

But today is still available.

So is tomorrow.

Whether it's a technical blog, a GitHub commit, a notebook filled with ideas, a personal journal, or simply sharing lessons on LinkedIn, every record becomes another chapter in a story that's still unfolding.

Years from now, those small pieces won't feel ordinary anymore.

They'll become reminders of how far you've come.

Conclusion

When people think about documenting their careers, they often focus on visibility.

Will recruiters see it?

Will it build a personal brand?

Will it create new opportunities?

Those questions matter.

But over time, I've realized they're not the questions that matter most.

The most important audience is often your future self.

One day you'll look back at the engineer you used to be and realize how much has changed. The technologies will be different. Your skills will have evolved. Problems that once seemed impossible will become routine.

What you'll miss aren't the polished achievements.

You'll miss the excitement of learning them for the first time.

That's why I wish I had started documenting earlier.

Not because I wanted more followers.

Not because I wanted more opportunities.

But because I would have loved the chance to meet the younger version of myself again.

And the only way to make sure my future self can meet the person I am today is to leave behind a trail worth following.

Building Software That Solves Real Problems

Writing is one way I share what I'm learning, but building software is where I spend most of my time.

I work with founders, startups, businesses, and organizations to design and develop scalable web applications, AI-powered solutions, cloud infrastructure, and custom software tailored to real business needs. Whether you're starting with an idea, modernizing an existing platform, or looking to integrate AI into your products, I'd be happy to help turn those ideas into something people can actually use.

You can learn more about my work or get in touch here:

Fastwork: https://fastwork.id/byob/7pFhYwWqZd?openExternalBrowser=1&source=byob

Upwork: https://www.upwork.com/services/product/development-it-custom-business-website-development-2067932090568948507?ref=project_share

About Me

Most days you'll find me building software, exploring new technologies, experimenting with ideas, and writing about the lessons I pick up along the way.

I'm fascinated by software engineering, artificial intelligence, cloud computing, system design, and the process of turning ideas into products that solve real problems. This publication is where I share what I'm learning—not because I have all the answers, but because I believe the journey itself is worth documenting.

If you're building something interesting, whether it's a startup, a research project, a community initiative, or a business that needs technical expertise, feel free to reach out. I always enjoy connecting with people who are passionate about building meaningful things.

#One of the Biggest Career Mistakes Is Treating Work as Life

restu ananda saputra — Mon, 22 Jun 2026 12:53:08 +0000

One of the more subtle mistakes ambitious people make is not working too hard. It is allowing work to gradually become the center of everything.

The process rarely happens overnight. In fact, it usually begins with good intentions. Most people start their careers with a simple goal: to create a better life for themselves. Work is the vehicle that provides opportunity, stability, growth, and the ability to pursue things that matter. There is nothing inherently wrong with that. Work can be deeply meaningful. It can challenge us, help us develop valuable skills, and create opportunities that would otherwise be unavailable.

The problem begins when the relationship quietly reverses.

Instead of work serving life, life begins serving work.

At first, the shift is difficult to notice because it often looks like ambition. You stay a little later to finish a project. You spend weekends learning new skills. You accept additional responsibilities because they create opportunities for advancement. You tell yourself that the extra effort is temporary and that things will slow down after the next milestone. The logic feels reasonable because every successful career requires periods of focused effort.

The challenge is that milestones have a habit of multiplying.

There is always another promotion to pursue, another client to acquire, another product to launch, another certification to earn, or another goal waiting just beyond the current one. What originally felt like a short-term sacrifice gradually becomes a long-term lifestyle. Before long, the future version of life you promised yourself remains permanently just out of reach.

I suspect many professionals spend years living in this state without fully realizing it. They become highly effective at managing work while becoming increasingly disconnected from everything else. Calendars are optimized. Projects move forward. Objectives are completed. Careers progress. Yet outside of those achievements, there is often a quiet erosion of the things that make success meaningful in the first place.

Relationships, for example, rarely collapse all at once. More often, they weaken through neglect. A missed conversation here, a postponed gathering there, and eventually the people who matter most begin occupying less space in our lives than the work we perform. The same can be said for health. Most people do not wake up one morning and decide to ignore their well-being. Instead, they repeatedly convince themselves that exercise can wait until next week, proper rest can wait until after the deadline, and stress is simply part of being successful. Years later, the accumulated cost becomes difficult to ignore.

Curiosity often suffers a similar fate. One of the most rewarding aspects of being human is the ability to explore interests with no practical purpose attached to them. Reading a book outside your profession, learning an instrument, pursuing a hobby, traveling somewhere unfamiliar, or simply allowing yourself time to think without a specific objective all contribute to a richer life. Yet these are often the first things sacrificed when work expands to fill every available space.

The irony is that many of these activities are not obstacles to success. In many cases, they are what sustain it. Healthy relationships provide support during difficult periods. Good physical health creates energy and resilience. Hobbies and personal interests introduce new perspectives that often improve creative thinking and problem-solving. A balanced life does not compete with professional success; it frequently makes long-term success possible.

This is not an argument against hard work. Meaningful careers are rarely built without discipline, sacrifice, and periods of intense focus. Every profession has seasons where additional effort is required. Entrepreneurs experience it. Researchers experience it. Software engineers experience it. Anyone pursuing ambitious goals will eventually encounter periods where work demands more attention than usual.

The distinction lies in whether those periods remain seasons or become permanent conditions.

A season has a beginning and an end. Permanent overwork becomes an identity. When every month feels like a sprint, when every accomplishment immediately leads to another obligation, and when rest constantly feels undeserved, something important has been lost. At that point, work is no longer helping to build a life. It has quietly become the life itself.

Perhaps this is why some of the most fulfilled people are not necessarily those who work the least or achieve the most. They are often the people who understand the purpose of their work. They recognize that careers are important, but they also understand that careers exist within a larger framework. Professional success is only one component of a meaningful life, not the entire definition of it.

Work matters. Achievement matters. Growth matters.

But the relationships we maintain, the experiences we collect, the health we preserve, and the interests we cultivate matter too. These are not distractions from life. They are life.

The danger is not working hard. The danger is reaching a point where work becomes so dominant that everything else is treated as an interruption.

Because at the end of the day, work is meant to support a life worth living.

It was never supposed to replace it.

About Me

I'm a Software Engineer, Applied Researcher, and Open-Source Enthusiast with interests spanning software engineering, artificial intelligence, cloud computing, system design, and digital product development.

Beyond writing, I work with founders, startups, businesses, researchers, and organizations to design and build scalable software solutions. Whether it's developing a new platform, modernizing an existing system, architecting cloud infrastructure, or transforming an idea into a working product, I enjoy helping turn ideas into reality.

I'm also passionate about supporting educational initiatives, student communities, research collaborations, and social-impact projects. If you're building something meaningful and need technical guidance, website development, or software engineering support, feel free to reach out. For selected community-driven and non-commercial initiatives, I'm happy to contribute on a voluntary basis whenever my schedule allows.

Technology creates opportunities, but meaningful impact comes from how we choose to use them.

The Fastest Way to Make an AI Project Expensive

restu ananda saputra — Sun, 21 Jun 2026 14:02:15 +0000

Over the past year, I’ve noticed a pattern in many AI discussions.

Someone describes a business problem. The team starts brainstorming solutions. A few minutes later, somebody says:

“Let’s build an agent.”

At that point, the conversation often jumps straight into frameworks, orchestration layers, memory systems, tool calling, and multi-agent architectures.

What’s interesting is that many projects never needed an agent in the first place.

The excitement around agentic AI has created a situation where teams sometimes begin with the implementation pattern rather than the actual problem they’re trying to solve. As a result, complexity enters the system long before anyone has clearly defined what the AI needs to know, what information it should access, and what actions it is allowed to take.

A more practical approach is to work backwards from the job itself.

Start With Understanding

Many AI applications only need to understand information, summarize documents, classify content, extract insights, or generate responses.

In these cases, an LLM is often enough.

The challenge isn’t building an agent. The challenge is designing prompts, workflows, and validation processes that consistently produce useful results.

Adding more moving parts doesn’t automatically create more value.

Then Ask Where Knowledge Comes From

The next question is whether the model needs information beyond what it already knows.

If answers depend on internal documentation, company policies, product information, or knowledge that changes frequently, retrieval becomes important.

This is where RAG and vector databases can be extremely useful.

However, I’ve seen teams use retrieval systems for problems that are actually database problems.

If a customer asks for an account balance, order status, invoice history, or CRM record, the answer usually shouldn’t come from a vector database.

A direct system query is often simpler, cheaper, and more reliable.

Access Is More Important Than Intelligence

Once an AI system starts interacting with business tools, the conversation changes.

Download the Medium app
At that point, the most important questions are no longer about model quality.

They’re about permissions.

What can the system access?

What actions can it perform?

What should require approval?

What should remain entirely under human control?

In many situations, a straightforward API integration is all that’s needed. More advanced approaches become valuable when organizations want a standardized way to connect multiple tools, systems, and data sources across different applications.

This Is Where Agents Begin To Matter

Agent design becomes valuable when the system must make decisions across multiple steps while handling exceptions, uncertainty, and changing conditions.

A support chatbot that answers questions from documentation may only require an LLM and retrieval.

A system that checks account information, validates policies, updates tickets, requests approvals, communicates with customers, and adapts to different outcomes is solving a very different problem.

That is where orchestration starts becoming necessary.

Not because agents are fashionable.

Because the workflow genuinely requires them.

The Real Engineering Challenge

What I’ve learned is that production AI isn’t defined by whether a model can use tools.

It’s defined by where you allow the model to exercise judgment and where the surrounding system maintains control.

The most successful AI projects rarely start by asking:

“How do we build an agent?”

They start by asking:

“What job are we trying to accomplish?”

Everything else usually becomes much easier to design after that.

AI #ArtificialIntelligence #AIEngineering #LLM #AgenticAI #SoftwareEngineering #SystemDesign #MachineLearning #RAG #Technology #GenerativeAI #ProductDevelopment #Architecture