Hey everyone, Sumit here. I have been building a coding agent for a while now. I’ve been building LLM-enabled applications for almost two years full-time, and I have a very different thesis around why I believe the world is going to be empowered with agentic coding, low-code development, or AI-powered coding—however you phrase it.
The idea for this product goes a long way back. I’ve held the nocodo.com domain name since 2013, and since then I’ve been developing ideas around how code generation could run at scale. This draws inspiration from Django, Ruby on Rails, and many frameworks where a single command can generate substantial amounts of code.
In the last 3-4 years, it has become increasingly clear that models are exceptionally good at generating code. In the last 6-12 months especially, so much has happened. New models emerge weekly, and I have a different perspective on this. This article introduces my opinionated approach to building software with coding agents.
The Architecture and My Approach
The way this project is built, its structure, and architecture are all exciting topics, but more important to understand is that this project itself is built using coding agents. I have barely written less than 100 lines of code in a codebase that is currently around 40,000 lines of code.
Lines of code don’t really matter. What matters is that I give demos almost every day and have early adopters as clients. I’m already onboarding a team from the US, and within India, I’m working with two or three teams. All this demoing, outreach, marketing, emailing, Twitter, LinkedIn, Reddit—I have time for all of it. I’m a solo founder and an engineer, yet I have time for all these business activities.
The reason I have time for them is because I don’t code by hand anymore. I don’t even review most of my code. Sometimes I need to sit through architectural decisions when something requires detailed planning, and we’ll walk through those things. This will be a video series I’m creating. I’m not a professional video creator, so please help me out with comments and feedback.
This product is itself created with either Claude Code or OpenCode. For OpenCode, I’m using models like GLM 4.6 or Grok Code Fast. This sets the context that I’m practicing what I’m preaching. I am an engineer with architectural thought processes and clear terminology, but that doesn’t have to be the case for everyone.
We’ve lowered the barrier to entry from coding every day to not coding every day—just having concepts is good enough. This project will be the kind of product that guides you through the entire process of building software without knowing all the technical jargon or architectural patterns. I’m not saying you won’t have to learn, but you won’t have to know them now—there’s a big difference. You can learn through the process of building, which is fantastic because your barrier to entry becomes even lower.
Who This Is For: Enablers vs. Multipliers
Who does this impact? Who is this for? There are two ways I look at it: enabler and multiplier. In my case, I’m getting a multiplier effect. I already knew how to code and build software. I’ve been an engineer for 16 years, been through at least 12-14 startups, and built and led teams across the US, Canada, Germany, and India. I’ve mostly worked remotely and worked with many great startups. I know how to code—I’ve been an engineering manager, engineering leader, and engineer, writing code for 20+ years. I still write code, but as a founder, I don’t want to.
As a solo founder, I have to do so much more. For me, AI is a multiplier when it comes to programming. But let’s say you’re not a programmer—that’s my aim and focus. My focus is on people who are not programmers but want to create software. For them, if you don’t know how to create software, this is an enabler because it allows you to do something you cannot do at this moment.
The multiplier effect is significant. I can probably do 2x-3x the work without even hustling. I don’t do a lot of overwork or burn 12 hours a day doing crazy stuff like you see all over the internet. I’m still producing software, my software is mature, I have demos, I’m reaching out, doing tons of these things, and I’m not killing myself.
Imagine that multiplier power. Now imagine that if you don’t know how to code and could suddenly unlock that capacity—that’s a massive enabler. You’ll get much more out of the system than I will because you’ll be able to do something you cannot do at this moment.
This is the first takeaway I want you to have. If nothing else I tell you is important to you, this should be the one thing you take away: you will have an enabler effect, the empowerment effect from AI, much more than I will because I already knew how to code and knew most of these other systems well.
As a solo founder or early-stage startup guy, I’ve learned deeply about analytics, marketing, sales, etc. I’m not a salesperson, but I do the rest fairly well. I didn’t have time before, so I got time because I could build software in an automated fashion. I extracted time from coding and invested it into other things as a founder should.
In your case, if you didn’t know how to build software, or you’re building a software-enabled business, or your business isn’t related to software but software is part of your workflow and you need customized software—this is the time you will go ahead and build it.
The ERP Myth and My Counterargument
Now, a disclaimer: there are many schools of thought and debated ideas. One side says you cannot build an entire SaaS, CRM, or ERP out of just low-code or agentic coding. To me, by the way, these terms overlap somewhat, but there are maybe some differences—though that’s not important for this first article.
I don’t think you will have to build those kinds of software, and this is where I draw the line. I don’t think every business is trying to build an ERP. The people who use that as their main argument—if you go on Twitter, LinkedIn, Reddit, they’re going to tell you, “Hey, don’t even think of building software with AI because you cannot build an ERP.” Who wants to build an ERP with agent coding? Nobody wants to.
If somebody says that’s the defense—that engineers are the only ones who will build software and nobody else can—I call on that because there are tons of existing software, particularly high-quality existing open-source software, which you can start building upon. You can build your business workflow. You can define your workflow on top of existing really high-quality open-source software.
I don’t believe SaaS is the future. I don’t believe that as a business owner, you have to be dependent on what software is already there by a platform person making hundreds of millions or billions of dollars just because they can create one software with tons of customized workflows and sell to millions of people.
I believe those millions of people can now customize existing out-of-the-box, available on-the-shelf open-source software and customize on top. I’m not saying you have to build an entire CRM yourself. I’m not even saying you have to build the CRM at all. So whoever is saying those things, I don’t believe them. That’s complete nonsense.
My Vision: Software Should Fit Your Business
According to me, what has to happen is that if I need a task management system for my team, manufacturing, and sales, and how it works is niche, I should be able to come in and define that niche, build on top of existing task management or other systems, and customize them in a way that my team’s workflow and my software fit each other.
In fact, the way it should be fitting is that the software I define should fit my business, not the other way around. In the current era of SaaS, you expect the business to fit into the SaaS. I believe that is going to end. I believe the end of that era has come.
I believe we should be able to take existing great-quality open-source software, which by the way means more money going back to open source. This is something I truly believe should happen. Developers who are building high-quality software and are engaged in open source should be better paid.
So taking a step back from all of these things, what are my high-level views? My high-level view is that AI is good enough to code. You do not have to start from scratch. So whoever says you have to build an entire ERP, don’t believe them. Do not go with them.
Believe that you have to define your custom workflows on top of existing high-quality software. I’m not talking about going to Lovable and creating something out of thin air. No, we don’t have to do that. You can take existing templates. You can take existing—even for Lovable, Replit, Bolt, Emergent—all of these platforms, they’re still using and they’re doing a great job of opening up the mindset that you can give your intent, your ideas, and build something.
But I’m saying let’s take this a step further and build entire full-stack applications because there are so many high-quality frameworks or open-source applications already out there. All we have to do is add some customizations on top. Of course, there’ll be edge cases where you’ll need to do deeper engineering or solve deeper software challenges, but we’ll get there.
Those are the main takeaways, and what I want you to focus on is that we can build software. We can create software that is according to what our business needs instead of the other way around.
How I Prompt: A Practical Example
Now let me walk you through how I prompt. What I’m going to show you might look geeky and technical, but let’s set aside the interface because I’m going to show you where I’m coding at this moment—which is a Linux terminal with Claude Code.
Before we get into those things, let me first walk you through how I think through things, and this is the most important part. Let’s say this is a folder where I have my project. This is one of the project’s many ideas I’m trying on. This is about project installation commands. If you can imagine a full-stack web application with frontend and backend, you’ll have these commands where you run the backend, build the backend, deploy the backend somewhere, or the same for the frontend.
Again, I’m going to explain what is backend, what is deployment, all of these things in future articles, but this is just an introduction. It may be a little scrambled and quick, but just hang on with me. I’m going to create a series of articles that will go through all of these topics. We’ll go through exercises. And by the way, I’m also hosting sessions. I’m hosting sessions where I’m teaching because I’m fully in on this. I have spent two years full-time. This is something I’m thoroughly convinced. My conviction is really strong. Just if you want to learn, if you want to see how you would be empowered by building your own software, I’m not charging you for this. This is going to be all free and I’m going to take sessions, I’m going to take classes.
Beyond the Basics
Again, I’m not starting from scratch. We’re not starting from “let’s build a homepage”—we’re not doing that. We’re already beyond that because the people I’m communicating with, I’m hoping that you on the other side have already tried Lovable, Replit, Bolt, Emergent, all of those things, so you know what it’s to build a homepage. If you haven’t, go try them, take up some learning lessons from there, and then come to my courses because my courses are a little more advanced—they need a little more background knowledge.
I’m going to fill in all the gaps when it comes to technical terms, understanding of architecture, how you prompt, what are the key terms you use when talking to AI, how to build documentation, how to anchor upon that documentation, how to take inspiration from existing open-source software. All of those I’m going to cover. But what I’m not going to cover is probably the basics like, “create me a homepage,” or change the color, change the buttons, etc. Those you should stick to the existing platforms which are already solving them. They have great free tiers. Go ahead, use them, build something, practice, then come back. I’m not going anywhere. Come back and watch my articles. Reach out to me. I’m definitely going to help you.
But I want you to do some homework. I want to see that you’re as invested as I am in this. Remember, this is the next 10 years of software that is going to change. Absolutely change. I have no doubts about it. If you feel that you want to get the most out of what AI can do, what LLM can do, I would say do a little bit of homework. Come back here, follow this channel after that, and then you will see the power coming through.
The Specific Prompt Example
With that aside, I’m going to talk about this particular prompt. I have a series of just three prompts since morning. So what is the context of this? Let me also show you the context of this project because without the context, it might not be clear.
So how I’m going to show you is I’m going to show you exactly how. This is going to be a little more detailed. But this is how I actually run my project. So I have a Windows client. I build the Windows client. I’m going to first pull my changes. I’m going to build the Windows client on Windows and then so these are the latest changes which came through. By the way, all of these lines of changes, all of these lines of changes are all AI coded. I do not write code anymore. Just for context, I’m going to keep repeating that many times throughout my articles. But just for context, I have stopped writing code. I need to make sure that you understand that this is the power that I’m going to be talking about. You can go from intent high-level thoughts dive into the planning or the architectural decisions. Do a little bit of homework, learn a little bit, bring in a friend, etc. That kind of collaboration. But we are not talking about hundreds of dollars per hour in development costs. We are not talking about that. We are beyond that era now. We are way beyond that era. So I do not write code and I want to let you understand. I want to rather explain how do I not write code but code is still generated. Software is still being generated.
So we go ahead we build the desktop application in here. I’m going to see if the backend is running. So the project has a backend and a frontend. Again we’re not focused on the details of this project because we’re not using it right now anyway. We are using cloud and we are looking at the prompts. The prompts matter because nocodo is also a code building software. So it’s still prompts at the end of the day. Right? So what I’m focused on is let’s focus on how do we shape prompts.
At the command discovery time in the manager. I know the manager is the backend and the frontend is the desktop app. There’s only the desktop app. Android and iOS apps are coming but they’re not built yet. So at the command discovery time. So what is command discovery? I’ll clear that out in a moment. Are we using our work items to store the communication between our LLM agent and the model? Okay.
So what is command discovery? Okay, so let’s log in and we’ll see what is command discovery. I log to my own local machine. So this is me from my Windows app connecting to the Linux which is running the backend. Okay, these details are not the most important at this moment but just to understand that I am connected to a backend. Here is a set of saved commands. Okay. Now these saved commands what they do is allow me to do things like run a project like I said. So commands are basically for me to run a project. So build a project run a project etc. This feature is not complete but there is something crucial here that I thought I would like to start off as the first article. So prompting is what I want to focus on.
So command discovery let’s come to command discovery the thing that we are talking about here these commands are actually discovered so let me go through a fresh project let’s say this is a fresh project I believe okay let’s take another project where the commands are not already discovered here is a big discover button okay when you click on this what happens is there’s going to be a start discovery process which means it’s going to look at the project I think this project cannot have commands because it’s an incomplete project doesn’t really have anything this one may have commands this is a stock viewer application let’s see yes it discovered these commands which means that it figured out that this is a rust based project. It could be by the way Python based project, Ruby based project, JavaScript based project doesn’t matter. It scans the files and there is an extra additional AI based verification process or rather AI based command generation process as well like command detection process we’re not using that but either case if you scan the codebase or if AI scans the codebase it doesn’t matter you basically quickly understand that okay this is a react project this can be built this can be run this can be dev run etc etc those commands are listed to you.
So now you see we discovered commands, and that’s just one example of how we work with AI to understand and interact with codebases.
Conclusion
This is just an introduction article. I want to cut it short here, but these key points I want you to keep in mind. If you like what I’m talking about, please feel free to follow, please reach out to me, and I’ll be more than happy to help.
Thank you.