Why the next generation of Internal Developer Platforms will be consumed through AI agents, MCP servers, IDEs, and terminals — not just portals.

We have been building Internal Developer Platforms since 2020 to reduce cognitive load for developers, provide self service, and still stay compliant through golden paths.

At least, that was the idea.

In reality, things are a bit more painful. Many organizations spend one to two years building a platform. Over time, this can easily cost three to four million. And after all that, the adoption rate is still often below 30 to 40 percent. Sometimes you even hear numbers below 10 percent.

And just to be clear. Building such a platform in one to two years does not mean it only needs one to two years of experience. It often needs five to ten years of engineering experience to even know what should be built in those one to two years.

And once the platform is finally ready, developers still bypass it.

Beautiful.

You built the platform. You created the portal. You documented the golden paths. You probably even added a nice landing page with icons.

And then developers ask:

"Cool. Where can I connect my agent?"

Or, in other words:

That is exactly the part I currently find so interesting.

I had the honor to represent the CNCF project OpenChoreo at CloudLand in collaboration with the CNCF and WSO2. During that event, and also during other conference talks, many conversations moved into the same direction.

We often ended up at the same two points.

First, people liked the idea of having a platform, an API, or a portal.

Second, they did not want to leave their terminal, their IDE, or their current AI assisted workflow to use it.

The message was almost always the same: the platform is useful, but the context switch is expensive.

A portal can be helpful. An API can be powerful. But both still require developers to leave their current flow. Sometimes that only costs a few minutes. Sometimes it takes 20 to 30 minutes until you are fully focused again. Not because developers are dramatic. Well, not only because of that. Modern software work is already fragmented enough.

Most developers now work inside their IDE, terminal, and AI assisted workflow. They jump between agents, repositories, clusters, prompts, pull requests, and probably too many Slack messages. The last thing they need is another browser tab with another login and another "quick" form.

This is where AI can change the adoption story of Developer Platforms.

Not because AI magically fixes bad platforms. It does not. A bad platform with AI is still a bad platform. It just answers in full sentences now.

But AI can make a good platform easier to consume. Instead of forcing developers to learn another portal, another workflow, or another API, the platform can become part of the tools they already use.

That is the real shift.

Developers do not need to go to the platform anymore. The platform can come to them.

This does not make the platform less important. It makes the foundation even more important. A Developer Platform still needs to be treated like a product. It needs a clear user problem, real self service, useful golden paths, security, compliance, ownership, and continuous improvement.

Otherwise you do not have a platform.

You have infrastructure with a nicer logo.

AI does not replace the platform.

It changes the interface.

Platform Engineering: Why AI is Changing the Developer Experience

To understand why I think AI changes the platform experience, we first need to separate a few things. Otherwise, everything quickly becomes one big AI soup. And nobody needs another soup, especially not in Platform Engineering.

In my view, there are three main ways AI can become part of an Internal Developer Platform. AI agents can run inside the platform itself. Developers can use external agents to interact with the platform from their own workflow. And platform engineers can use AI to extend, operate, and improve the platform faster.

Let us start with the first one.

Building AI-Native Developer Platforms: Internal Agents in OpenChoreo

OpenChoreo already comes with three built in AI agents. The FinOps Agent analyzes Kubernetes resource usage and cloud cost data from OpenChoreo components. It can generate reports with cost optimization recommendations, cost attribution, rightsizing suggestions, and other useful insights.

The SRE Agent focuses on root cause analysis. It looks at logs, metrics, and traces from OpenChoreo deployments and helps generate reports with likely root causes and possible next steps.

The Portal Assistant is a chat assistant inside OpenChoreo. It is read only by design. It can list, get, and query information, but it cannot create, update, delete, or trigger anything. Which is good, because giving every chatbot write access to production sounds like a great way to create a very expensive incident report.

These agents are integrated into the platform control plane, but they run as part of the observability plane through Helm chart configuration.

The important part is not only that these agents exist. The important part is how they are integrated.

Agents need access to platform data. They may need logs, metrics, traces, cost data, component metadata, and sometimes access to external LLM APIs. That means security cannot be treated as an afterthought.

By default, OpenChoreo configures ThunderID as the identity provider for the SRE Agent with a pre configured OAuth client for testing purposes. If you already use an external identity provider, you can configure that instead. Client IDs, tokens, and LLM API keys are managed through the built in OpenBao vault setup and ExternalSecrets.

There is much more going on here from a security and platform operations perspective, but I do not want to turn this article into a deep dive about identity, secrets, and Helm values. We are here for the AI adoption story.

The key point is simple: AI agents are not just added as a nice demo feature. They are treated as real platform participants. That also means they need identity, permissions, secrets, boundaries, and access to the right context.

Because OpenChoreo is built around the concept of planes, you can take this idea further. If you do not want to use an external AI API, or if regulation does not allow it, you can build your own AI plane.

That could mean running open source LLMs, adding your own domain knowledge, and creating richer context for the built in agents. This becomes especially interesting for regulated industries like healthcare, finance, or government, where data protection is not just a nice slide in a PowerPoint deck.

In that case, an AI plane gives you more control. You can decide where models run, what data they see, how access is handled, and how much domain context they get.

And this is where the platform idea becomes powerful. The platform does not only expose compute, networking, deployments, and observability. It can also expose AI capabilities in a controlled and compliant way.

Through the built in agents in the customized Backstage portal, you can inspect incidents, look at Root Cause Analysis (RCA) reports, and ask the agents to explain why something failed. This is possible because OpenChoreo is already designed with AI agents in mind.

Looking under the hood, the important part is that AI does not sit next to the platform as a random extra feature. It becomes part of the platform architecture. It needs access to the same signals, APIs, identities, policies, and operational data that other platform components use.

That is also why this topic is bigger than simply adding a chatbot to a portal. A useful AI integration needs context. It needs boundaries. It needs a clear role inside the platform. Otherwise it is just a very confident search box with a higher cloud bill.

This brings us to the next important point. A Developer Platform is not only used by software developers. This is often misunderstood.

Platform engineers use it. SREs use it. Security teams use it. Architects use it. Product teams may use it. And now, AI agents also start to interact with it.

That means we need to think about all of them as platform citizens with different goals, permissions, and guard rails.

So far, we looked at AI from inside the platform. Now we need to look at the other side: the people using the platform, and the agents they bring into their own workflow.

Developers as Platform Citizens

Now we have AI agents inside the platform. Great. But most platform users are still humans. And in most cases, these humans just want to build something, run it somewhere, and not spend half of their week understanding how the infrastructure sausage is made.

That is why platform engineering exists in the first place.

Platform engineers define golden paths. They make sure workloads are secure, compliant, observable, and maintainable. They hide complexity where possible and expose just enough control where needed.

At least, that is the idea.

To understand why external agents and local AI workflows are so interesting, we first need to look at the old pain again.

In the past, or maybe still today in some companies (if -> run), a developer needed a database and opened a ticket. After some waiting, the result was not a database. The result was a virtual machine.

Congratulations.

You asked for PostgreSQL and received an operating system.

Now please install the database yourself, configure backups, think about patching, set up monitoring, and try not to cry into your keyboard.

Yes, this is slightly exaggerated. Slightly.

And yes, the cloud made this better. In many cloud environments you at least get a managed database with a default configuration. But not every organization is fully cloud and api native, not every team has the same level of automation, and not every internal service feels like the cloud provider demo from the keynote.

If the developer does not want "OS as a Service" and actually asks for a real database service, the next step is often a feature request.

That sounds reasonable until you remember how ticket based environments usually work.

If the request fits the standard, things might move. If it does not fit the standard, it becomes slow. Very slow. The developer waits, explains the same thing again, adds missing information, joins a clarification meeting, waits again, and eventually gets something that is close to what they asked for.

Close, but not quite.

Come on, guys. At least pretend you looked at the request.

With cloud, APIs, automation, and proper self service, this situation becomes much better. A platform can provide standardized environments much faster. Developers do not need to open a ticket for every basic need. They can consume predefined building blocks and get something that works most of the time.

This is where Developer Platforms are powerful.

Standardization makes scaling easier. It improves Day 2 operations. It helps platform teams support more teams with fewer custom snowflakes. It also creates a shared way to deploy, observe, secure, and operate workloads.

But standardization also has a downside.

The moment a team needs something outside the standard path, things become harder again. Every custom request increases the burden on the platform team. Every exception makes it harder to provide a simple self service experience for everyone.

This is where many platforms start to struggle.

Especially when the platform was built mainly from an infrastructure point of view. Then it often becomes declarative configuration as a service. Useful, yes. But not always developer friendly. It may solve the infrastructure problem, but not the user experience problem.

And developers think differently.

They usually do not want to understand every custom resource, every controller, every internal naming rule, and every environment promotion detail before they can ship something.

They want to build software.

Wild idea, I know.

When developers are unhappy with the existing self service, they ask for changes. That is fair. But this is also where speed often disappears again.

The platform team now needs to understand the request, check if it fits the platform model, decide whether it should become part of a golden path, and then implement it in a way that does not break the rest of the platform.

At the same time, developer teams still need onboarding. They need to learn the portal, the API, the pull request based configuration flow, or whatever interface the platform team provides. And that's on top of their daily job.

Even if the platform is good, there is still friction.

And this brings us back to the workflow problem.

Most of us now work inside an IDE or terminal with AI support. My current workflow looks more like this:

I try to avoid portals when I can. Not because portals are useless. They are still helpful for discovery, visibility, demos, onboarding, having a single pane of glass and for people who are not working on the operational level every day.

But every switch costs time.

Every new interface pulls me out of my current context. And once I am out, getting back into the same flow is not always instant. Sometimes it takes a few minutes. Sometimes it takes much longer. Sometimes I just wanted to check one thing and suddenly I am reading Slack, checking email, and wondering why I opened the browser in the first place.

A classic enterprise productivity journey.

Now imagine the platform does not force me to leave that workflow.

Imagine I can keep working in my IDE or terminal and still interact with the Developer Platform in a safe and controlled way.

I do not need to know every internal API. I do not need to search through the portal. I do not need to copy values from five different places. I can ask my local agent to help me create, inspect, or prepare the right platform resources based on the standards defined by the platform team.

That is where OpenChoreo becomes interesting as a Developer Platform.

It can expose platform capabilities to the tools developers already use, while still keeping the platform model, the golden paths, and the governance in place.

This is the part that could increase adoption.

Not because developers are forced to use the platform.

But because using the platform starts to feel like part of their normal workflow.

Putting Everything Together to Capture the Big Picture

So far, we looked at the pieces separately. We looked at AI agents inside the platform, developers as platform citizens, external agents, and the workflow problem that appears when people need to leave their IDE or terminal just to consume a platform capability.

Now let us put the pieces together.

OpenChoreo becomes interesting here because it is designed for both sides of this model. It supports built in agents that are part of the platform, but it can also expose platform capabilities to external agents through interfaces like MCP.

At first, that may not sound too special.

A secured MCP server running on the control plane. Nice. Another integration endpoint. Another box in the architecture diagram. Very enterprise. Very rectangle.

But that is not the main point.

The main point is that the interaction model changes.

In the past, if I was a developer and wanted to use a self service platform, I first had to understand which components existed, what they were called, which fields were required, which workflow I had to follow, and where the documentation was hiding this week.

As a platform engineer, the situation was different but not easier. If I wanted to provide or extend self service capabilities, I had to understand how the platform controllers worked, how the custom resource definitions were modeled, how components were extended, and how all of this should be exposed without breaking the golden path.

With AI as an interface, both sides can work closer to their natural workflow.

Imagine a developer building a new lightweight database service that should later be used internally across the company. The company already defines how software should be built, which API standards must be followed, how services are exposed, and which rules apply before something becomes visible to other teams.

When the developer is ready, they do not need to click through a portal, manually call an API, or search for the correct YAML example from three months ago. They can extend an agent skill, use an existing one, or simply ask their local agent:

I want to deploy this new database service on our Developer Platform. For now, it should only be visible to the QA team.

Based on that request, the right OpenChoreo resources can be prepared. Depending on how the company defines the workflow, those resources can then be applied through GitOps, reviewed through a pull request, or handled through another controlled process.

The important part is not that the developer skips governance. That would be a terrible idea, and also a great way to meet the security team under less friendly circumstances.

The important part is that governance becomes part of the workflow.

The developer stays in the same environment. The platform still defines the rules. The agent helps connect both.

What makes this even more interesting is that platform engineers can work in a similar way.

Imagine a platform engineer extending the platform with a dedicated AI plane because the company works in healthcare and is not allowed to use external AI APIs. No data should leave the company boundary, and no internal data should be used by an external provider for training, improvement, or whatever the current terms of service politely call it.

The platform engineer still needs to understand the architecture, the planes, the security model, and the domain requirements. AI does not remove that responsibility. But the engineer can use the same workflow pattern to explore examples, reuse existing documentation, inspect how other planes are structured, and generate a first version of the new AI plane.

They do not need to reinvent the wheel. They can use the platform context inside their own workflow.

That is what I find especially interesting.

Developers and platform engineers used to live in very different tool worlds. Developers had their IDEs and repositories for building software. Platform engineers had infrastructure code, cluster controllers, and policy engines for governing the underlying cloud.

AI as an interface can bring these worlds closer together by abstracting some of the underlying tools while still keeping the platform model intact.

Of course, this sounds very nice in an ideal world.

And because we are talking about AI, we should be careful. A lot of this space is still moving fast, breaking in strange ways, and producing impressive demos that need a human nearby with strong coffee and production access.

But we should also be fair. Kubernetes itself has features that spent years moving through maturity levels. In Place Pod Resizing, for example, took a long journey from alpha to beta. So maybe we should not expect every AI integration to behave like a perfectly mature enterprise product after one conference demo.

Still, the potential is huge.

Let us take the previous developer example again. The developer wants to deploy the new database service through OpenChoreo. But it does not work because the platform does not yet provide a component type for that kind of database workload.

Instead of leaving the workflow, collecting screenshots, writing a half empty ticket, and explaining the context again, the developer can let the agent create a feature request based on what was built.

The agent already knows the current task. It understands the repository context. It can inspect the current OpenChoreo setup. It may also use an internal template or a custom MCP server that knows how feature requests should be created inside the company.

That means the request can contain the right information from the beginning.

Not perfect. But much better than "Please add DB thing. Urgent."

If the company has good rules and templates in place, the feature request can already include the required information, documentation, examples, and even machine readable details.

The platform engineer can then pick it up inside their own workflow and start implementing the missing platform capability.

This does not mean there is never a need for direct communication between developers and platform engineers. Sometimes there absolutely is. Talking to people is still allowed, even encouraged, even in 2026.

But many simple requests do not need three meetings, four clarification rounds, and a ticket that slowly becomes archaeology.

If the request is structured well, the platform team can react faster.

Depending on how far AI automation is adopted inside the company, the next step could even be a solution proposal generated from the feature request.

That does not mean the system should blindly ship changes into production. Please do not let a random agent redesign your platform at 2 a.m. because someone wrote "make it scalable" in a ticket.

But it can generate a draft. It can suggest the required resources. It can prepare a pull request. It can help platform engineers move faster while they still review, refine, and own the final result.

And this is one of the reasons why I believe AI can increase Developer Platform adoption.

It gives developers a more flexible interface than a fixed portal with three approved buttons. At the same time, it does not remove the platform rules, the golden paths, or the platform team.

It creates a better loop.

Developers can express what they need in their workflow. Platform engineers can react inside their workflow. The platform remains the foundation that keeps everything secure, compliant, and operable.

Now, at this point, someone will ask the obvious question.

If AI agents can talk to APIs, MCP servers, tools, and cloud platforms directly, why do we need a Developer Platform or a platform team at all?

Valid question.

Let us look at that next.

Why Do We Still Need a Developer Platform?

At this point, the obvious question appears.

If developers can use AI agents, MCP servers, APIs, and cloud services directly, why do we still need a Developer Platform or a platform team?

In theory, and in many startups, you can get pretty far without one. Small teams can move fast with direct cloud access, a few scripts, some Terraform, and enough shared context in people's heads. It works until it does not. Classic architecture strategy.

In enterprise environments, the situation is different. These organizations are usually more regulated. They need established patterns, support models, auditability, ownership, operational responsibility, and teams that can provide support when things break at 2 a.m. Because things always break at 2 a.m. Apparently production has a calendar.

That is one reason.

But the more important reason is experience.

Everyone who has ever tried to build an internal environment for development and production workloads knows how much knowledge, time, and discipline this requires. You need deployment models, network rules, secrets, observability, security policies, compliance checks, cost controls, incident processes, lifecycle management, and a lot of decisions that nobody sees when everything works.

And that is exactly the problem.

When platforms work well, they look simple from the outside. When they do not, everyone needs suddenly becomes an infrastructure expert in the incident channel.

Developer Platforms like OpenChoreo cover much more than I can explain in this article. If you are interested in the full picture, it is worth looking at the project in more detail. But for this article, I want to focus on one part that matters a lot for AI adoption: the Experience Plane.

The Experience Plane is interesting because it does not only think about "the developer" as one generic user.

It looks at different platform citizens with different needs:

• Developers
• Platform Engineers
• AI Agents

Each group has different goals. Each group needs different permissions. Each group needs different guard rails to stay compliant with company policies, industry rules, and in many cases also state or EU regulations.

And this is where the AI story becomes more concrete.

AI agents are not just tools floating somewhere next to the platform. They need to be treated as platform citizens as well. They need identity, permissions, boundaries, and access control. In that sense, they are not completely different from machine accounts or service accounts. They can help, but they should not be allowed to run around the platform like an intern with admin rights.

OpenChoreo is being built to treat AI agents as first-class participants." — Sameera Jayasoma, Distinguished Engineer, WSO2

This is why a Developer Platform still matters.

Someone has to provide the foundation. In most companies, that is the platform team. They define the interfaces, operating model, golden paths, compliance rules, and platform capabilities that others can safely consume.

Developers need a simple and efficient way to run their workloads securely and compliantly without understanding every detail below the surface.

Platform engineers need a way to build and evolve that foundation without turning every request into a custom snowflake.

AI agents need to be enabled safely. They should support developers, platform engineers, and other users either from inside the platform or through controlled access to the platform. But they also need restrictions, permissions, and clear responsibilities.

Without that foundation, AI does not remove complexity. It just gives complexity a nicer chat interface.

And yes, of course, not everything works perfectly yet. Some use cases already create real value. Others still cost more time than they save. That is normal for a space that is moving this fast.

So let us do a quick reality check.

OpenChoreo Hands-On: Production Reality Check & Prompting Challenges

Now let us do the part that is usually missing in AI articles.

The reality check.

Because yes, AI integration in Developer Platforms is exciting. Yes, the potential is huge. And yes, some parts already work surprisingly well.

But not everything is magic. Some things are still rough. Some things need real platform engineering experience. And some things work great in a demo until you try them with your own identity provider, your own security rules, and your own very special enterprise network setup.

What Works Well

The integration of AI agents into the platform works well once everything is set up correctly. The results are useful because the agents are not guessing from thin air. They have access to real platform context.

For example, the SRE Agent can use logs, metrics, traces, application data, and controller information to generate better answers. That makes a big difference. An agent without context is just a very polite random number generator. An agent with the right context can actually help.

I set up the FinOps Agent as well, but I did not test it deeply. It requires OpenCost, so keep that in mind if you want to try it yourself.

The portal integration is useful when you want to inspect incidents, look at RCA reports, or ask the assistant to explain what happened. This is especially helpful for people who do not want to jump directly into logs, traces, metrics, custom resources, and controller behavior.

Not everyone wants to start their morning by reading Kubernetes events.

Shocking, I know.

The MCP integration with observability also works really well for many use cases. You can connect the MCP server to your AI workflow and use it to inspect platform data from your existing tools.

The demos are worth trying because they help you understand what the MCP server exposes and how you need to prompt to get useful results.

You can ask questions about deployments, environments, observability data, incidents, and platform resources. This gives developers a much better way to understand what is happening without leaving their workflow every five minutes.

This is where the experience becomes practical. The developer gets access to the information they need for daily work, while the platform still controls how that information is exposed.

If you want to see this in action, the live webinar includes a demo showing how an incident looks and how an AI agent helps based on the RCA report.

What Does Not Work Perfectly Yet

Setting up the AI agents was not completely trivial. Connecting them, understanding how they are integrated into OpenChoreo, and understanding how communication is secured takes some experience. This becomes especially relevant when you bring your own identity provider.

For developers, the entry point can feel quite smooth once the platform is ready. For platform engineers, the work is different. You can get OpenChoreo installed and configured, but once you start integrating your own company logic, your own domain model, and your own compliance rules, you need to understand the OpenChoreo concepts properly.

That is not a weakness of OpenChoreo. That is platform engineering.

Every tool can bring useful defaults. No tool knows your company, your industry, your internal rules, your audit requirements, your naming conventions, and the one exception that apparently exists because someone made a decision in 2018 and nobody dares to touch it now.

OpenChoreo brings a lot out of the box, but the platform team is still responsible for defining golden paths and compliance for their own environment.

One example is adding another environment stage.

By default, OpenChoreo works with three environments:

Dev → Staging → Prod

If your company needs four environments, for example Dev → Staging → UAT → Prod, then the platform engineer needs to define that model.

During the webinar, we tested this unscripted and unprepared because I was curious how well it would work after first hearing about the feature at KubeCon EU 2026.

The task was mostly completed and the result was useful. But this is also where the reality check matters.

Prompting matters.

In the example, the desired pipeline should have been Dev → Staging → UAT → Prod. But because the prompt did not clearly mention the full flow, the result missed the Dev environment.

That is not dramatic. It is actually a good example of how these systems behave today. They can generate a strong first version, but you still need to understand the result. You still need to know the custom resources. You still need to review whether the output actually matches what you wanted.

The good part is that you get a useful skeleton. From there, you can continue prompting, iterate on the result, add agent skills, or keep a human in the loop for review and refinement.

And honestly, sometimes the problem is not the model. Sometimes the prompt is just bad. We all like to believe our thoughts are perfectly clear until we ask an AI system to turn them into YAML.

Another thing to keep in mind is the model and endpoint you use. If you work with public AI APIs, the results are often quite good. If you use custom endpoints with older models and no internet research capabilities, the output can become strange, especially because OpenChoreo is still a young project and changes quickly.

For platform engineers, more support is coming as well. There is an Architecture Agent planned (I heard some rumors) that should help adapt OpenChoreo architecture to a specific company domain.

And that is the real potential I see.

AI will not remove the need for platform engineering. But it can make the platform easier to consume, easier to extend, and easier to adopt across an organization.

That is already a very big deal.

Final Thoughts

AI will not replace Developer Platforms, platform teams, or golden paths. Security, compliance, and core infrastructure operations still need human expertise and domain knowledge.

But AI is fundamentally changing the way developers want to interact with those systems.

If you are a platform engineer building or maintaining an IDP today, here is your takeaway: Stop thinking only in web portals and start thinking in context servers. The next generation of your platform's API should probably be an MCP server. By exposing your platform capabilities as structured context for LLMs, you ensure that your platform goes wherever the developer's workflow goes.

It's not about making the platform less important. It's about making it less annoying to access and that might be exactly what we need to finally fix the adoption problem..

Want to Know More?

If you want to learn more about OpenChoreo, I recommend starting with the repository, the roadmap, discussions, and examples. Since OpenChoreo is a CNCF Sandbox project, you can also join the CNCF Slack channel and follow the project there.

You can also watch the webinar "Sovereignty in the Age of AI: Control, Transparency, and the Future of Platforms". It is not only about AI, but near the end you can see OpenChoreo in action, including the AI integration.

For a deeper view into the AI native direction, I also recommend Lakmal Warusawithana's talk:

The best way to learn is still hands on. Reading blogs is nice. Breaking things locally is where the real learning happens.

Quick Start Guide: https://openchoreo.dev/docs/getting-started/quick-start-guide/

MCP Servers: https://openchoreo.dev/docs/ai/mcp-servers/

FinOps Agent: https://openchoreo.dev/docs/ai/finops-agent/

Example Catalog: https://openchoreo.dev/docs/getting-started/examples-catalog/

Another Blogs / Videos:

• OpenChoreo: The Secure-by-Default Internal Developer Platform Based on Cells and Planes | Blog, Artem Lajko
• From Cell-Based Architecture to OpenChoreo | Blog, Erandi Ganepola
• Building a Kubernetes Platform — Think Big, Think in Planes | Blog, Artem Lajko
• K8s Maxxing with AI-Native Platform Engineering Stack with OpenChoreo | Video, Bret Fisher
• OpenChoreo: An Open Source Blueprint for Internal Developer Platforms | WSO2Con, Video, Sameera Jayasoma

Contact Information

Got questions, want to chat, or just keen to stay connected? Skip the Medium comments and let's connect on LinkedIn 🤙R. on't forget to subscribe to the Medium Newsletter so you never miss an update!

If you found this useful, please feel free to share it! It really helps, and it lets me know that I should keep creating more content just like this!