When Code Stops Being the Bottleneck: Custom Tools for Any Shop

Madhuranjan Kumar of a widely used AI coding tool made a public claim that most software developers would have dismissed as exaggeration eighteen months ago: over a full month of active development on his own product, he wrote zero lines of code by hand. Every change, hundreds of commits representing tens of thousands of lines, was generated by AI. He was not describing a prototype project or a side experiment. He was describing his actual development workflow for the tool other developers use every day to build software faster.

The month that changed how one builder talks about his own tool

What makes the claim worth examining carefully is not the number itself but the context. This was not a simple internal script or a throwaway demo. It was an actively developed commercial coding tool, complex enough that its own author was using AI to build it. The recursion matters. If AI-generated code were too unreliable for production use, you would not use it to build the very product intended to help developers ship production code. The fact that the workflow held up at that level of complexity sets a higher ceiling than most skeptics have allowed.

The language practitioners use to describe their own work has shifted meaningfully alongside this. The framing has changed from describing the outcome clearly as a nice-to-have skill to calling it the new core skill outright. That is a significant relabeling. It means the bottleneck has moved. The limiting factor is no longer the speed of writing syntax or the familiarity with a particular framework. It is the quality and precision of the brief. A person who can explain exactly what a piece of software should do, in specific enough terms that a coding agent can work toward it without constant clarification, produces results faster than a person who types code faster but describes goals less precisely.

For businesses that need custom tools built, this shift has a practical implication. The most important thing you can bring to a development session is a clear description of the outcome, not a technical background. That levels a playing field that has been tilted toward developers for decades, and it is why the cost and time for small custom software projects is falling faster than most owners realize.

What the queue workflow looks like from inside a real session

Modern coding agents work in a pattern that looks different from traditional development. You describe a goal, the agent begins building toward it, and you go do something else. Minutes later the agent has written code, run it, checked the output, and fixed the errors it encountered. You come back, review what was built, describe the next step, and the cycle repeats. The work is intermittent direction-giving rather than sustained coding.

This queue structure is different from the pair-programming metaphor most people use when they first encounter AI coding tools. Pair programming implies working side by side in real time with someone who needs constant guidance. The queue model is closer to managing a fast contractor: you brief the job, the work gets done while your attention is elsewhere, and you come back to review the output. Modern agents can run for minutes or hours on a well-scoped task with light supervision, which means a session can produce substantial results without occupying your full attention.

For a business owner who wants a web-crm integration, a custom reporting tool, or a booking flow that actually handles their specific pricing rules, this queue structure means the development session does not have to consume their entire day. The work happens between other tasks. The review can happen when the session is done. That accessibility is one of the most underappreciated aspects of how this workflow changes who can commission software.

The skill of writing a good brief, being specific about inputs, outputs, and edge cases, turns out to be a skill most experienced business operators already possess. They have been writing briefs for designers, copywriters, and contractors for years. The same discipline applies to directing a coding agent, and the feedback loop is dramatically faster than any human contractor relationship.

Three app versions in an afternoon, and what that number represents

Developers using current coding agents report completing three distinct versions of an application in a single afternoon: work that previously took one to two weeks per version. That number matters not because speed is intrinsically valuable but because of what exploration becomes possible when the cost of a version is measured in hours rather than weeks.

When building three versions takes three weeks, you build the best version you can think of and ship it. You cannot afford to explore alternatives. When three versions take an afternoon, you try the most obvious approach, observe its limitations, try a different architecture, compare the two, and arrive at something better than any single approach would have produced on its own. Speed enables exploration, and exploration produces better software.

For a business thinking about a specific internal tool, three versions in an afternoon means the exploration phase is essentially free. You can try a simple version, see whether it handles your actual workflow correctly, find the edge case where it breaks, and fix the architectural choice in the same sitting. You are not committed to the first design decision. You can iterate toward the right answer quickly rather than living with the first reasonable answer because building a second version is too expensive.

For owners thinking about meta-ads reporting tools, invoice generators, or client-facing booking systems, this speed matters because the first version of a custom tool almost always reveals something you did not know you needed. A field you thought was optional turns out to be required. A workflow step you thought was rare turns out to happen three times a day. The three-versions benchmark is the measure of how quickly you can get from guessing at what you want to knowing exactly what you want and having it built correctly.

How skills files teach an AI agent the specific way you work

One of the less discussed capabilities of modern coding agents is the ability to accumulate learned preferences over time through instruction files that practitioners call skills. A skills file is a set of instructions and examples that tell the agent how you want it to approach a specific class of task. It might specify the code style you prefer, the testing approach you expect, the naming conventions you use, the structure you want for particular component types, or the architectural patterns your specific project follows.

Without a skills file, every new session starts from zero. The agent applies sensible defaults that match general best practices but may not match the specific way your system was built. With a skills file, the agent reads your preferences before starting and applies them consistently across every session. The tool becomes calibrated to the specific way you work rather than the average way developers work in general.

This matters practically for any business building and maintaining its own tools over time. The second time you add a feature to a custom tool, you want the new code to match the style and conventions of what was already built. Skills files make that automatic. They also capture the business-specific knowledge that would otherwise need to be re-explained in every session, so language about your workflow, your naming conventions, and your data structure is part of the agent's starting context rather than something you have to reconstruct each time.

For teams building google-ads reporting integrations or custom dashboards that connect multiple data sources, skills files can encode the specific field names your business uses, the calculation logic that defines your key metrics, and the format that matches how your team actually reads performance data. That calibration reduces friction in every subsequent session and produces more consistent output over time.

The small custom tools a business could not afford to commission before

The practical implication for most businesses is not that they can replace a development team. Most businesses do not have one. The implication is that they can now commission or in some cases build themselves the small custom tools that used to fall below the minimum viable project size for a freelance developer.

A booking form that integrates with a specific calendar system and sends confirmation messages. A quote calculator that applies your actual pricing rules rather than a generic estimate template. An inventory tracker that flags reorder points for your specific product mix. A job board scoped to your industry and location. A simple dashboard that pulls your google-ads numbers and your booking numbers into one view so you can see both at once. A client status portal where customers can see where their project stands without calling the office.

Each of these used to require finding a developer, scoping the project, negotiating a price, waiting for delivery, and paying for any changes after the fact. The minimum viable project cost was high enough that most owners wrote them off and built workarounds instead. Those workarounds, spreadsheets and manual copy-paste and multi-tab browser sessions, are the friction that slows a business down at the moments when it should move fast.

To illustrate the shift concretely: consider a service business owner who invests one afternoon directing a coding agent to build a job intake form that routes new requests to the right team member based on service type and location, sends the client an automatic confirmation, and logs each new job in the spreadsheet the team already uses. Previously this would have been quoted as a week of developer time at a meaningful cost. Run through a coding agent with clear specifications, the same tool comes together in a session, and the owner reviews finished pieces rather than managing a developer relationship. The ongoing cost is zero.

The quality check that keeps the whole system honest

The enthusiasm for AI-generated code should come with a clear and honest account of its limitations. Code that passes the initial test may still fail on edge cases, and edge cases in business software are exactly where failures cost the most. A booking tool that works for 95 percent of appointments but fails silently on bookings that cross midnight, or on customers in a different time zone, can cause real problems before anyone notices the pattern.

For anything that touches money, customer data, or the safety of a business-critical workflow, the quality check must be slower and more careful than the build itself. This means testing with real data rather than only the happy-path scenario the developer imagined. It means asking someone outside the build process to try to break it by doing what real users actually do. It means, where the stakes justify it, reviewing the generated code itself rather than only testing its behavior.

The right framework is the simplest version first. Build the smallest tool that does the specific job you described, test that it handles your actual use cases correctly, and only then extend it. Every feature added to a working tool is a potential new source of failure, and the discipline of adding only what proves its value keeps the system honest. Generated code that is too complex to understand is generated code that is too complex to maintain, and a tool that runs correctly but cannot be maintained is a liability rather than an asset.

Madhuranjan Kumar advises clients to apply the same quality standard to AI-built tools that they would apply to any tool touching customer-facing workflows. The bar is not perfection on the first pass. It is reliable correctness on the specific tasks the tool was built for, verified through real-data testing before it goes live. Get that right before expanding the scope, and the system earns trust incrementally rather than requiring it all at once. That incremental trust is the thing that turns a session-built tool into a permanent part of a business workflow rather than a prototype that never quite made it to production.