When Software Becomes Everyone's Job [Testμ 2026]

From Zero to Many Builders

Count how many people outside your engineering team ship software today. Not spreadsheets or filtered dashboards, but live applications other people depend on.

At Piramal Finance two years ago the answer was near zero, and the session is the account of how that changed.

Their framing is that AI now touches the whole journey: imagining what to build, building it, validating it, and shipping it. The more consequential shift is not what AI does but who is now able to do it.

The person with the idea no longer waits for someone else to write the code, and the boundary between business, product, engineering and operations has blurred. In their reading, AI stopped being a developer tool and became a software creation layer.

The first phase was conventional enough. They rolled an AI coding assistant across the whole engineering organisation over roughly six months, and work that had taken months started taking weeks, then days.

The Tatkal Squad

People outside engineering noticed and asked the obvious question. If AI is writing the code, should technology not cost considerably less?

The response was an experiment squad named tatkal, after the Indian railway booking tier for urgent same-day tickets. The promise was that any feature handed to them would be in production within 48 hours.

The scope was deliberately bounded to ordinary systems needing CRUD operations and a few integrations rather than high-complexity work. Delivery went from months to hours, and business was delighted.

It worked well enough to become a problem. The squad turned into the most in-demand team in the organisation, which they were candid enough to call an anti-pattern.

The lesson they drew is that delivery speed was never the whole constraint. Demand for software is effectively infinite, so the bottleneck reappeared as the number of applications they could ship rather than the time each one took.

Build Your Own Tech

That pushed them toward a different question: where do engineers actually matter?

Their worked example is a daily reporting portal for frontline loan sales staff, replacing informal updates sent over chat and calls. It serves up to 5,000 people and amounts to straightforward CRUD.

A core system processing loans, carrying compliance obligations and handling sensitive data is a different matter, and engineers are unambiguously needed there. Separating those two cases is what opened the door.

The resulting idea is what they call BYOT, or Build Your Own Tech: a platform built by engineers on which business teams build and ship their own internal tools.

They were careful about what it is not. This is not handing everyone access to production systems, but a controlled environment where the person who understands the business problem can turn it into a working application.

Platform Problems, Not Coding Problems

Their first instinct was to teach business users to be developers. They explained front end, back end and APIs, installed Node.js on their laptops, and gave them access to an AI coding tool.

To their own surprise, it worked. The applications were not toy demos but genuinely useful tools, because the people building them understood the business better than engineering could.

Then they hit the wall. How does the app get deployed, where does it run, who owns the API, who manages secrets, and how does monitoring work?

Their illustration is port 3000, permanently occupied because everyone is developing, so apps drift to 3001, then 3002, then 3003. None of that is a coding problem.

Returning to first principles, they concluded that if business users could already build good applications, they should not have to learn deployment or hardware at all. So the platform absorbs it.

Setup was the first thing removed, with an editor running in the browser and no local installs or dependency management. Builders describe what they want, then click once to go live.

Underneath, authentication, databases, ports and secrets are pre-wired. Engineering standards are not relaxed; they are encoded as guardrails so the builder never needs to know the rules the platform is already following.

The Numbers

They admitted they had not expected the scale it reached.

• 947 builders - people across the organisation building on the platform.
• 1,306 projects - created on the platform in total.
• 369 applications - live in production and in real use.

They stressed that these are not prototypes or hackathon demos. They are applications people rely on, built by business but still governed by engineering.

That split is the part they credit for making the model scale. Business holds the capability to create, engineering retains the ability to govern, and neither role collapses into the other.

KriyaOS and the Loop

BYOT solved building and deployment, which still leaves most of a software lifecycle untouched. Requirements, design, sign-off, UAT and post-deployment monitoring had all remained engineering’s burden.

KriyaOS is their attempt to embed the rest of it, described as an operating system for software creation. The loop runs in six steps.

• Shape note - a one-page illustrated requirement generated from a meeting, transcript or idea, setting out the workflows the system will implement.
• Mockups - generated once the shape note is approved, filling the role a design team used to.
• Build - which begins only after the mockups are agreed.
• UAT - an ephemeral link with the app on one side and a chat interface on the other, where feedback becomes tickets in the platform automatically.
• One-click fix - the builder presses fix, and the change routes back to whoever raised the issue.
• RCA agent - after deployment it watches for error responses and log patterns, raising tickets that re-enter the same fix loop.

The sequencing carries a cost argument as well as a quality one. Building first invites long iteration loops, and changing a component repeatedly burns tokens that translate directly into spend.

So nothing is coded until the idea is agreed. Shifting the decision left lowers cost and improves what the model eventually produces.

The Engineering Layer Underneath

The obvious question, once business teams are building and shipping, is what engineers are doing. Their answer is that engineering moved up a layer rather than away.

• Skills repository - roughly 30 skills encoded from their own standards and patterns, so an AI session starts with the organisation’s way of building rather than a blank page.
• MCP integrations - connecting AI to the tools used for monitoring, deployment, project management and design, so it operates inside the engineering environment rather than only generating code.
• API catalog - internal APIs exposed as tools, so a business application needing something that already exists does not rebuild it, and the builder never sees the plumbing.
• Starter kits and secure defaults - authentication, secrets and port decisions made once by engineering and inherited automatically by everyone building.

The shift they describe is from solving a problem per application to solving it once and distributing it through the platform. Less code gets written by hand, and by their account there is more engineering than before, not less.

Quality as a Wall

Building software in hours creates a problem for anything that used to take days. There is no room left for a quality process that runs at the old pace.

Their answer is a quality lifecycle that generates itself. Every application gets integration, regression and smoke tests automatically, rather than because a developer remembered to write them.

It runs as a mandatory CI gate, and the enforcement is automated end to end. A failing test makes the system raise its own ticket, identify the problem, attempt a fix, and re-run rather than waiting for someone to notice.

Their reasoning is symmetry. Code already ships at AI speed, so quality has to run on the same loop or it becomes the next bottleneck.

The Apps That Never Launched

The most useful part of the talk is the arithmetic they did not hide. Of 1,306 projects created, 369 went live, which leaves 937 that did not.

Allowing perhaps 200 still in progress, roughly 700 sit abandoned. First-time users experiment, duplicate projects, and take practice runs, and all of it consumes resources and tokens amounting to thousands of dollars.

Their defence of that spend is a specific case from the collections team. The first app disappointed them and was scrapped, the second likewise, and the third was an automation that reduced a recurring activity from 30 days to 5 minutes.

They were careful to call that an extreme case rather than the norm, and to point at improvements in the 20 to 30 percent range as the realistic pattern. Multiplied across 369 live applications, they argue the return covers the abandoned 700 comfortably.

The structural argument underneath is about the long tail. With roughly 20,000 people in the organisation, even a fraction having one idea a quarter generates thousands of ideas a year.

An idea that saves two people half a week each is genuinely valuable to them and will never survive prioritisation against organisation-wide work. Small ideas die, and the platform is what lets them get built anyway.

The Decisions That Stay Human

Their sharpest example of the platform earning its keep involves a feature it refused to build. The collections team wanted their live follow-up tracker to upload a customer list and send automated reminders.

AI drafted it in minutes and reached for a third-party messaging API. It could not proceed, and the reason matters: no engineer caught it in review and no security scanner flagged it.

Applications on the platform can only call services exposed through the approved API catalog, so the risky path does not exist to begin with. They describe this as closed by design rather than by luck.

The platform prevented a technical risk without making a business decision. The team still had to settle whether customer contact data should be used this way, what consent existed, and when and how any message should be sent.

Rebuilt on the approved internal gateway, the feature shipped the same week. Their reading is that the constraint shaped the feature rather than blocking it.

That leads to what they deliberately keep away from AI, on the grounds that speed is not the same thing as judgment:

• What to build and why - AI can help explore solutions, but choosing which customer problem deserves solving stays with people.
• The boundaries themselves - the platform enforces security and compliance rules, while deciding what those policies should be does not move.
• Core platforms and complex systems - writing a lot of code is not the same as architecting, and knowing when something works technically but should not ship is judgment AI does not supply.

Q & A Session

The session ran close to time, so one audience question was taken before the close.

• If software is everyone’s job, how do you prevent shadow AI or misuse of AI tools in the workflow?

  Gurleen and Keerthivasan: It comes down to the guardrails built around whichever tool you adopt. Even general-purpose coding agents ship with limits, such as being unable to authenticate into a system on their own, and those exist for a reason. On their platform, secrets, deployment and authentication are never written by business users; they are pre-built into every application from the start. Layered on top is role-based access, so an engineer and someone from HR hold different permissions, which is what keeps shadow usage from taking hold.

Their closing lesson was about belief rather than tooling. Telling someone in business they can build an application themselves usually meets disbelief, because they have spent a career assuming that is what engineers are for.

So they started with tiny applications solving small real problems, one after another, letting each success change someone’s mental model. As they put it, you cannot install a mindset, you grow it one application at a time.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.