The Next Layer of Developer Experience - Mohit Gupta

In this talk, Mohit discusses enhancing developer experience through the integration of AI into the development process. He emphasizes the importance of reducing friction from idea to production, likening it to the improvements seen in retail shopping. Mohit highlights the architecture at Lowe's India, which operates at scale across various cloud platforms, and introduces the concept of a context layer for AI coding agents. By providing the necessary contextual knowledge and decision-making frameworks, developers can leverage AI more effectively, transforming it from a novice into a valuable teammate. He outlines a playbook for building this context layer, including actionable steps like making documentation AI-eligible and packaging knowledge into agent skills. The ultimate goal is to enable AI agents to operate autonomously and efficiently, thereby improving productivity and business outcomes.

Could I travel back in time with me? So, think back to your first task as an engineer. You went through the onboarding wiki. You maybe installed your ID. You checked the best practices and all of that. And then you wrote the code. Now, chances are, unless you broke production on your first task, you got stuck much before that. You probably did not have the right Kubernetes config

or you missed the deployment issue or anything. Or something entirely else. Now, chances are that you got someone to pull up the chair next to you and tell you exactly how the system works. Now, it was the problem was not that you did not know how to code. The problem was something completely different. And today, AI is exactly like that eager fresher. It knows everything about the

world. It is in fact even changing it, but it does not really have that real operating knowledge. Now, with the next layer of developer experience, we are going to change that. I'm going to tell you exactly how you can upgrade AI to that teammate who pulled the chair and in the process pull yourself ahead of the competition. So, good morning, everyone. My name is Mohit and we

are going to uh talk about technology and platform architecture. Now, quick context about my company. Lowe's India is a GCC which is powering the $86 billion retail chain in US. Now, whether it is tech, business ops, finance, everything runs here. We are a Fortune 100 company and we are the second largest home improvement retailer in the whole world. Now, this is the scale at which we operate

and everything I'm about about to talk about today has been tested at this scale. So, let's get into it. Okay. All right. So, let's start with agreeing on what developer experience really is. So, is it dark mode on your IDE or a good coffee conversation? Well, that is developer's experience, but developer experience is something little different. It's the friction in the process from an idea to production.

And the goal is not just to make things faster, but also keep things safe. Now, I'll take an analogy from retail itself. Now, over years of iterations, we have reduced the friction to shopping from just being a click of a buy now button. The It takes your money, it knows your address, and it is extremely convenient. If we apply that same product rigor to platforms is what

creates developer experiences. Now, the what that means is the platform is the product. Your developer is your customer, and the goal is to make the right path the easy path, and the easy path the right path. Now, let me show you the Lowe's engine room for some context. Under the hood, it's not a single platform, but a platform of platforms. At its core, we have our compute

and fabric that spans across our internal cloud, our private cloud, public cloud, as well as our edge computer on all the stores. Next, we have our data layer. This comprises of managed databases such as Postgres, and so on, along with data movement platforms such as Kafka, Flink, etc. And then we have the integration plane. This enables us to govern east-west as well as north-south traffic, enabling internal

partner as well as agent to agent integrations. And then we have something we call the product and growth enablers. Now, these are custom platforms which solve very very specific needs such as AB testing or feature flags or session recording and replay or BPMN workflows, etc. And then on the right, you will see the observability platform. Now, this is the logs, metrics, anything that we need to monitor,

keep these platforms reliable, as well as any application running in Lowe's. But, while this looks great, there is something missing. A developer needs to know how to use Kubernetes, how to provision a DB, or just simply get the link to the Grafana. And that's where we had to build a bunch of buy now buttons, which is essentially the internal developer platform. We call this the Lowe's engineering

console, and it helps us uh any team in Lowe's to not just operate, but even discover or do anything with any of these platforms. if we zoom out, we see that a developer experience needs to cater to these three layers. The first is the knowledge layer. This is everything about when or how to use the platform. Next is the means to interact with the platform, which is

SDKs or APIs or any of those things. And then we have the execution layer. Now, you can imagine this as a self-service discovery portal or a dashboard, anything really which helps you govern or operate your platforms. And I think most of you have either used or built something like the engine room and interacted with these three layers already. And this all looks great, but there is a

big problem. Our user is now changing. It's no longer just a person with a keyboard, but also their AI coding agent, and which we never interviewed while we were building any of this. So, let's take the next slide. Let's rewind a little bit. Is the world changing for the first time? So, the bottleneck to shipping software has always been shifting. A few years back, it was all

about writing large enterprise code bases, and architects were everywhere, maybe writing class diagrams or UMLs just to manage that complexity. But then we got past that, and the bottleneck shifted to provisioning infrastructure. Now, this is when you had the code, but a server would take 3 weeks to come. But then we solved that with cloud again. The bottleneck shifted. This time it was about writing enterp- distributed

event-driven services, managing containerized ecosystems, and so on. And then came the AI boom, of course. Now again, at Lowe's, we leaned into this aggressively. We built everything internally from autonomous agents that should review each and every pull request to personalize developer assistants which would help them operate all of those platforms that we spoke about. But, we still hit a wall because the bottleneck is actually shifting yet

The new bottleneck is agent context. How do we ensure, while agents are doing really great at operating things and coding things autonomously, can we give them the right decisions, the patterns, and the practices that we've followed so over the years? Let me take an example. Now, let's say I have a simple problem. I have a new checkout button, and I want to roll it out using my

feature flag Now, yesterday I would expect the developer would go read the platform docs, understand all the SDKs available, uh set up the flag on the portal, maybe, and then finally write the boilerplate and see it work. Today, the developer does not want to do any of that manually. They just want to go to to their agent and tell it that, "Hey, here's a button. Can you

put it behind a flag?" But, it does not work. The AI is going to do one of two things. One, it is either just going to put a configuration file locally and use that to just as a flag, or it is going to invent its own feature flag platform, which is basically what we call hallucination. Now, what do we do? I think most of you are thinking

that, "Okay, I can just go back and tell the AI that, 'Here, here are my docs. Here is my SDK. Here is maybe my tenant ID or my flag name. Can you now go and write the code?'" And I'm sure it'll make progress. But, the amount of progress will entirely depend on the translation. Did you supply all the correct documentation? Did it actually even fit in its

context window? Or did you even correctly configure the flag in the first place in the portal? And this is just a button that we are talking about behind an on/off flag. Imagine the pain if you are trying to integrate a payment provider, or if you are simply trying to add a new uh analytics tag on your website, ensuring that it does not catch anything sensitive. how do

we solve this? This is what I call the last mile problem. We need to make sure that our agents get the right platform context so that they can operate more autonomously. They can become our teammates instead of us having to all translate our problems all the day. There's a little bit something frustrating about this as well or I would rather call it borderline unfair. If you were

say working against a platform such as Google Analytics or Stripe payment system, this same agent is going to work a lot better. Because our platforms are private. They do not exist in that same public memory and the LLM does not have access to thousands of GitHub repos, thousands of Stack Overflow threads. And that's what the context layer needs to solve. I introduce the context layer as something

which provides the decision rules, constraints, patterns, etc. to an AI agent. Now, if you have been to more conversations, you would have come across this buzzword called AI golden paths. This layer is exactly the answer to that problem. But, there is actually something bigger hidden superpower with this layer that you can get. Now, traditional developer experience that we spoke about in the past is all about influence.

So, you build the right portals, you give the easiest to read docs, easiest to use tools, and then expect that the developer would engage with all that content and they are going to use that and follow the right path. And of course, there is some level of opinions and assumptions that will shape the final solution. But, now for the first time, we can actually achieve a little

inversion of control. We can actually be part of the agent's reasoning session while the downstream solution is getting built and influence it accordingly. And that's the superpower. It's essentially like pulling up a chair to to an AI agent in the entire world. So, this sounds great, right? But, how do we build the context layer? And in the next few slides, I'm going to give you the exact

recipe to do that. let's look at how an agent actually knows. Now, of course, there is an LLM which has been trained on a lot of data, so most of its knowledge come from the comes from the training data. But, for everything else, it has something called a context window. Now, unlike humans who have a long-term memory and a short-term memory, and we can learn from our

experiences, consolidate that back into the long-term memory, agents cannot do that. And that's why their short-term memory is the window is limited. So, how do you get past that? Because if it fills up, the agent is going to forget things, and its performance is going to go down. So, we build architectures around this, and the most basic form is just compaction. So, as soon as you hit

the overflow, you forget the details, just remember the big picture. But then, of course, you can even do things more dynamically. Just pull in the context when it is required, so that you avoid that overflow in the first place. Now, coming to coding agents, they follow these four approaches to do exactly that, to pull the context dynamically when it is needed. So, let's talk about system rules.

These are your root-level instructions sitting in config files such as a claw.md or a cursor rules, depending on your ID, and every time you talk to an agent, it's going to load this instruction into its Second is the local workspace. Now, this is basically on the file system which you have currently open in your ID. Now, this could have code, docs, downloaded dependencies, anything. And whenever you

prompt the agent to do something, it's going to pull out the relevant section, and then build on top of it. Next, of course, is active tools, which could be web search, it could be any command lines that the agent can run, and also, of course, MCP tools. And then finally, we have something called a semantic index, which I believe most of you are familiar with. It's essentially

the rag. Some agents can index all of that local context, including your project workspace, etc., into the rag, and then pull it on demand as they need to be more efficient. Now, these are the exact ingredients that we will use to build our recipe. So, let's get into that. I've distilled all my learnings into five steps of this playbook. The first step is AI-eligible docs. This is

just about making your docs readable. Second is workspace delivery. You can think of this as meeting the agent where it's already there in the project Third, it is the agent skills. Now, if you see this Pareto line, these first three steps are the 80/20. These are going to give you more than 80% of the impact, realistically, with less than 2 weeks of effort combined. Now, when we

really need the upgrade, we can move to MCP server. But then, the impact here onwards is going to be completely incremental. And then last, we have the memory loop. You can imagine this as again a rag, which has all your platform context, its documentation, code bases, maybe decision logs. And then it is coupled with a self-improving feedback loop. And that feedback loop's job is to collect failures

from your agent touchpoints, your IDEs, and then use that to improve the context. So, in the next couple of slides, we are going to cover all these three steps in detail. We're going to talk about the MCP server as well. And then towards the end, I'm going to share a QR code which which can take you to a live demo which you can try with your own

agents. All right. So, we'll start with the simpler version, which is the LLMs.txt first. So, while there are many ways to make your docs AI-eligible, I'm just going to cover this one because this is the most powerful one and I'm going to tell you why. Now, if you're familiar with robots.txt or sitemaps, they tell search engine bots what to scrape and what to ignore from your website.

LLMs.txt is the exact same uh this thing the uh concept for AI agents. The idea is that you just put a markdown in a specific location on your website and it tells the agent everything about it. Now, in our context, it's not just a general web website. We are talking about platforms. So, all we need is a very simple version of this with three The first is,

of course, the title of your platform. The second is an optional description. It could tell the agent about when to use this platform, what are the top use cases, and so on. And then, the most important part, which is the list of your documentation, which can guide that agent to the golden path. Now, this is just a single static file, and it's in markdown. So, which makes

this very, very version controlled. Friendly, it is very auditable. And, as you can see there, it's the best first move because it is uh it is very easy to implement as well. Now, uh you you can also imagine that because now it's all markdown instead of a website, you have no HTML CSS bloat, so it is very context efficient as well. Now, if I come to the

uh standard, this is an emerging standard, so it's not universally adopted, but there is a lot of momentum. So, if you look at most documentation tools today, such as Docusaurus or uh Ment- Mentlify or GitBook, they all support this and, in fact, automate this for you out of the box. And some other tools uh documentation tools that you might be familiar with, they just need a plugin

install. There's enough community to do But, at the same time, let's say you're like me, and your docs live in a confluence or a legacy wiki or a custom website or a mix of all of them. Even in that case, you can use things like Crawl for AI or Firecrawl. Just curate the list of your docs, pass on those URLs, automate that pipeline, and you will have

something which is self-maintaining even without having to change your documentation tool. And you can realistically do this in less than a day. Only effort is going to be to figure out what your top maybe 15 to 20 docs are which have the carry the most signal. let's take step two. The idea behind the doorstep delivery is very, very simple. How can I make sure that the agent

gets my platform context even if the user forgets to pass it along? And all we need to do is use to our context on one slide the system rules. We need to make sure that we can update the system rules, upload all our platform knowledge in that in the in that folder, and that's all there is Now, while every agent does it differently, Cursor has cursor rules

and Claude has claude.md. We everything is converging to a single standard called agent.md, and that's what we just need to use. So, now the problem converts to uploading the platform knowledge in this making sure that it gets peer-reviewed, committed, and it becomes part of the project forever. how do we do that? Now, we don't have to own that file. All we need is a thin root-level instruction,

something like that you can see on the right, which points the agent to further detailed documentation with And even though you know, this is an emerging convention, today almost all top IDs, literally everything that you're using the most popular 20 IDs already support this out of the box today. Now, how do we do this? So, there are many ways to make sure that you can update this

file. One is of course a zero infra copy base. You can just share the developer that hey, this is what you need to put it there. On the internet, you will find something which I would advise against though, right? So, you will see that there are very highly implicit ways to do this. So, you can maybe package it as a post-install SDK hook, but I would really

advise against that mainly because just imagine this. If you're building at scale, especially if you're building externally, you do not want a Trojan horse in your library, which is feeding unreviewed instructions to an agent which has access to privileged environments potentially. So, the easy way would be something like this, a context initialization script or a command which does this for you. It downloads your platform docs locally.

It checks it into the project. It also updates the agent.md in the root, and that's all there is to it. And you can even simplify that. You can skip the download and just point it to the llms.txt if you did that in step one. And as you can see here, there are other ways to deliver it. You can be more creative. Not going to cover everything, this

is this is all about the doorstep And you'll be surprised with just two steps, about two to three days of effort, you can achieve a lot of impact. But it is still not going to be enough to upgrade your agent from a fresher. So, let's talk about the next one. Now, with agent skills, you can package all your platform knowledge, tools, context, everything into a single folder.

And that folder only needs to have three The first is the skill.md. It can even be the only file in your skill, but the skill I I would recommend using this more as a router or a map because your platform platform could evolve, your context could grow. So, you don't want to put everything here. Instead, you can use the references directory where you can put all your

detailed documentation. And the way the skill is designed, the agent is going to use the router to figure out and pull in the context from the specific documentation it really needs to at the time it needs to. So, it makes it very context efficient for a platform of any skill. And lastly, we have the scripts folder. Now, this is what really elevates the skill to the next

level. So, think about this. The scripts are what can give agents access to tools that they can run So, from our feature flag example, now the agent cannot just write correct integrations for your feature flag, but it can even provision that on the portal for you automatically. Or it can even discover your let's say Kafka topics, maybe their schemas before you write the client code. So, anything

really which you want your developers to do frequently can be packaged as a script and the agent is going to do that automatically even without the user having to tell it or lift a lift a finger. Now, coming to the delivery, skills are arguably easier to deliver than even our step two. So, instead of modifying a file, all we need to do is put it in a

specific location inside the project directory and the agent is going to load it automatically. And now, if that was not easy enough, uh skill marketplaces are also coming up. In fact, there's a new package package manager for skills called NPX skills, which has recently come up. this is all great, right? Uh but to answer your question as well as the next slide, uh why do we need

skills and why can we not skip to the MCP server? My recommendation is that most platforms would not even need anything beyond a And let me explain why with the next Now, let's compare the two and I'll tell you what the trade-off is and when the upgrade is really justified. So, with skills, we established that it follows all the context and code benefits. It is very easy

to implement. It's all markdown. And it also is very, very uh like there's zero infrastructure that you have to maintain, so it's very easy to maintain as well. It's all client-side. But where things start to break down is when your context is evolving too rapidly. Let's say your docs are changing every few hours or your tools are getting so heavy that they're hard to keep compatible across

client environments. And that is when an MCP server can allow you to pull back that control to your own infrastructure by having a remote But you lose all those benefits that we spoke about. So, you do not get all that simplicity. You still have the same abilities with tools and uh but now you also have to figure out how to uh deliver context progressively by keeping it

context context efficient for the agent. At the same time, dealing with JSON RPC and server-side events and So, that is why the trade-off is big enough. I would recommend that you should not treat them as competitors. Instead, treat them as complimentary. Start with a skill. See where it starts to hurt. So, let's say you find yourself dealing with stillness too often or you find yourself requiring some

central authentication control or simply, if you know about MCP apps, if you require rich interactive UIs to be provided to your users, that is when the upgrade for just that part of the workflow to an MCP is worth Otherwise, you can just continue to use if you have to remember something here, it's exactly that, right? Treat them as complementary. Build the skill first. The mistake is not

stopping at skill. The mistake is not choosing it over MCP, but the mistake is just starting with the heavier one by default. Okay, so we'll move on to the next Yeah, so let's see where the world is at, right? So, if you look at the top platform leaders, they're already arriving at very similar answers. So, if you look at Vercel, they recently launched along with a package

manager, they also updated their create next app CLI to auto-wire the agents.md, which is the doorstep delivery that we spoke And this happened as early as January. Now, if you look at Stripe, they've updated their agent toolkit, which they've been offering for about a year, to now include tools. So, you can create through your ID payment links or even billing schemas right from there. If you look

at Google, Google very recently, just this month, they've launched an MCP for Gemini Docs. Now, Gemini is at the forefront of AI and therefore it is evolving too rapidly. So, this is the answer to the stillness Now, even though the implementations are drastically different, everyone is arriving at the same answers that you just need to package your context, publish your workflow, and you have something which uh

you you you need a server only when you need something live. good. Yeah, so here is the part which will resonate most with executive leaders or business teams. Now, while this is all great for internal, it improves your developer productivity, it helps you move faster with fewer mistakes, but the real game changer is external. Now, at Lowe's, we are expanding our omnichannel business. We are trying to

onboard more partners to our catalogs, to our carts, to our payment services. But, the partner developers hit the same last mile problem that we spoke about. So, today, when I have to explain to a partner about how to integrate the map catalog, I need to tell them about store level pricing and explain them over weeks of calls. But instead, what I can do is I can package

my contacts layer and they can just type it into their IDE that can you integrate the Lowe's catalog or cart and see something working in the next few minutes. And therefore, on the next call, instead of telling each other our catalog or price flows, we can actually talk about growing the business. And that's what's changing the economics of integration. It means that I can activate my partners

a lot faster. I do not need to spend time translating my platform. It also means the support cycle is going to be a lot lesser. And lastly, the most important part, it is going to result in very very consistent experiences, which means our customer, whether they're shopping on first party lowes.com or a third party partner application, let's say even chat GPT, they will get the same experience.

And that's the real power. And it also helps our business teams negotiate exclusive partnerships, preferred partnerships with so many vendors in the home improvement industry. So, that's a real game changer. uh this is one of the last slides. So, I hope by now I've convinced you that we are at a massive inflection point. Platform engineering is evolving, the bottleneck is shifting, our user is changing from the

person at the keyboard So, what can we do about this? You can start as soon as Monday. Don't have to boil the ocean. Just identify one API, maybe one SDK, one tool which is causing some pain, some friction. Execute the playbook. Just do tools, simple things. Start with the LLM sort of thing on day one, maybe do the agent sort of thing on day two, do the

agent skill the next week, and start seeing the impact. All you need to then do is repeat this playbook. So, it's you you scale it up to your other platforms, scale it up externally. You can build your competitive mode around this by having zero friction So, the mantra is stop having your AI operate like a fresher now. Make it a real teammate, give it the tools, teach

it how to use that, and see your business grow. Okay, so this is the live demo. It's a self-guided demo, so I'm not going to show it here. You can actually scan this. It's going to take me take you to to my GitHub. You can follow the instructions. You'll be able to see llms.txt, agent skill, MCP, and you can actually test it against your own IDs as

So, with that, I hope you have already visited this stall, too. You cannot miss it, the Lowe's booth. I hope to see you all there, and thank you so much for your time. >> [music]