DEV Community: restu ananda saputra

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