Planning

I write the specs with help from an AI assistant. They cover the product goals, features, user journeys and user experience. A second AI then reviews the plan and looks for gaps and weak assumptions. After that, I break the work into small feature slices, and each one has a clear definition of done. My favourite pair for planning is Fable 5.1 with Sol 5.6 or Astra.

Building

A coding agent builds each slice. It has access to the codebase, the data store and my architecture and coding guidelines. It writes unit, functional and regression tests as it goes. Current favourite for building: Fable 5.1 or Opus 5.5.

Review

A different coding agent reviews the code, and another does a security review. Each review runs for a set number of rounds, with a clear point at which to stop. I use a different agent for review because an AI checking its own work tends to miss its own mistakes. Current favourite pair for review: Opus 5.5 for execution and Sol 5.6 or Astra for review.

Guardrails

• The AI drafts an architecture diagram, and I review and improve it.
• I use database tools to check security and performance.
• I review third-party dependencies for supply chain risk.
• Code follows SOLID and DRY principles, and cyclomatic complexity stays under 20.

I stay in charge throughout. The agents do much of the work, but I decide what gets merged.

Acceptance and release

I check the result against the acceptance criteria with AI help, and then I test it thoroughly by hand. Any feedback goes back to the build step. Once a slice is accepted, it goes to production using deployment playbooks.

What I feel is that software development is now largely automated. The agents write the code, the tests and much of the review. My job has shifted from writing code to deciding what to build, setting the rules and approving what ships.

When an agent writes code, it doesn't need us to simply trust that the code works. It can compile it. Run the type checker. Execute tests. Run CI. Observe runtime failures. Software doesn't have perfect oracles, but it has unusually rich ones. That creates a powerful loop:

generate → execute → verify → correct

And that loop is a big part of what makes autonomous coding agents viable.

Now try the same thing in finance. Ask an AI agent:

"What was my gross margin last quarter?"

A general-purpose model can read some transactions, do arithmetic in its context window, and confidently return a number.

But where is the compiler? A hallucinated code function fails immediately. A hallucinated tax liability might fail six months later, when an assessment notice arrives.

That is the provenance problem I've been thinking about while building finance agents at TrackBooks: how does a financial answer prove where it came from? How do we make sure the same underlying data and accounting rules produce the same answer every time?

My current design bet is that finance isn't actually oracle-poor. It is oracle-fragmented.

The oracles already exist. The P&L engine knows how revenue and expenses are classified. The balance-sheet engine knows how accounts roll up. The ageing engine knows which invoices are outstanding. The reconciliation engine knows whether two sets of records agree.

The mistake is asking the language model to recreate these systems inside its context window.

So in our architecture, the model does not perform authoritative accounting computations. It does something narrower. It understands the question. It decides which instruments to use. It calls them. It chains their outputs when necessary. And it explains the result. The tool, not the model, becomes the unit of trust.

1. Report engines are the strongest tools

The highest-confidence tools simply expose the same deterministic engines that already produce financial reports: P&L, balance sheet, cash flow, receivables ageing, payables ageing.

If the agent answers a question using one of those tools, there is no separate "AI version" of the number. It is using the same computation path as the underlying accounting system. That matters. The model can misunderstand a question. It can choose the wrong tool. It can explain something badly. But it should not be inventing a second implementation of accounting logic.

2. Finance also needs its equivalent of grep

Coding agents don't spend all their time compiling. They spend enormous amounts of time searching: grep, find, read.

Finance agents need the same second layer, because no fixed report engine can answer every possible business question.

Our answer is guarded, read-only SQL over curated financial views. The agent can search transactions, compare periods, inspect parties, identify unusual movements, and combine those results with the deterministic reporting tools.

The hierarchy is deliberate: report engines first; guarded retrieval for the long tail. If a trusted engine already knows the answer, use it. If it doesn't, give the agent safe instruments for investigating the underlying data.

3. Every tool should carry its own evidence

This is where provenance becomes more than simply "the AI used a tool." A trustworthy financial result should be able to carry things such as:

• the source data or records used
• the accounting period
• filters and parameters
• the data snapshot
• the tool or engine version
• reconciliation information where applicable

That gives us three separate properties:

• Deterministic computation. Accounting logic runs outside the model.
• Provenance. We can trace where the answer came from.
• Reproducibility. The same data, rules, parameters and versions should reproduce the same result.

None of those guarantees that software can never contain a bug. But they make financial answers inspectable, testable and auditable in a way that arithmetic generated inside an LLM simply isn't.

4. Writes need a different contract

Reading financial data is one thing. Changing it is another.

When our agents begin creating journal entries, bills, reconciliations or other financial actions, those will also be tools, but with a human explicitly built into the contract. Something like:

propose → explain → approve → revalidate → execute → audit

The agent proposes the action. A human approves it. The system re-checks that the underlying state has not changed. The deterministic tool executes it. The audit trail records what happened.

So the rule becomes: reads require provenance; writes require provenance plus authorisation.

The interesting part is how this architecture compounds. Every new tool converts another category of questions from "the model worked it out" to "a deterministic system computed it."

At the same time, every improvement in foundation models makes the agent better at understanding questions, selecting tools, chaining them, investigating exceptions and explaining results. Those two improvements are largely independent. More verified tool coverage raises trust. Better models raise orchestration intelligence.

So that's my current thought process and roadmap for finance agents: keep building tools. The models will keep getting better at playing them.

I suspect this pattern extends well beyond finance: law, tax, medicine, compliance. Any domain where getting the answer wrong doesn't immediately throw an exception.

The interesting question may not be "how do we make the model know the domain well enough?" It may be "how much of the domain can we turn into instruments that carry their own proof?"

Most of that spend happens not at the model-training layer but at the inference layer. Inference is where trained models are actually used to generate outputs: predictions, text, code, images, audio or video. NVIDIA defines inference as the process where a trained model applies learned knowledge to new inputs in real time.

That is where the money is flowing every day.

For Indian users, much of this spend currently goes to foreign platforms: ChatGPT, Claude, Gemini, Cursor, Midjourney, Runway, ElevenLabs, OpenRouter, Replicate and other global API and app providers. For heavy users this is already meaningful. A single professional paying $20, $100 or $200 a month is not unusual. At national scale, developer and creator AI usage is becoming a serious recurring forex outflow.

The lowest-hanging opportunity is not necessarily to build a frontier model from scratch. That is expensive, uncertain and research-heavy. The more practical opportunity is to build a sovereign Indian inference cloud: ready-made API endpoints for high-quality open-source models, optimised for coding, content generation, Indian languages, OCR and document AI, voice, and business automation.

This is a better first business than foundation-model training because:

• Demand already exists. Developers and creators are already paying.
• Open-source models are good enough for many workloads. Coding, summarisation, content generation, translation, OCR, extraction, voice and agent workflows do not always need the most expensive frontier model.
• Billing can be prepaid. API credits, prepaid wallets and monthly packs create strong cash flow.
• Gross margin improves with utilisation. Once GPU infrastructure is purchased or leased, the business becomes a utilisation game.
• Backward integration remains optional. Cursor is a good example of an application-layer company that created monetisation first, then gained leverage to move deeper into models and infrastructure. Public reporting suggests Cursor scaled extremely fast, crossing very large ARR milestones within a short period.

India is already moving in this direction. The IndiaAI Mission says eligible users can access subsidised AI compute, with 18,000+ GPUs mentioned on the compute portal, while later government communications reported 38,000+ GPUs onboarded under the mission. Sarvam is building Indian-language sovereign models. Companies like Yotta, E2E and Neysa are building AI and GPU infrastructure.

But the gap is still open: India needs a simple, reliable, developer-friendly inference product, not just GPU rental.

The winning product would look like this:

OpenAI-compatible APIs, billed in rupees, hosted in India, with optimised open-source models for coding, content, Indian languages, OCR, speech and enterprise automation.

The real moat would not be GPUs alone. The moat would be model routing and cost optimisation; low-latency serving; fine-tuned models for Indian business use cases; SDKs and OpenAI-compatible APIs; prepaid rupee billing; enterprise data-residency positioning; and reliability and throughput.

The challenges are real: capex, GPU procurement, power, cooling, utilisation, serving efficiency, model benchmarking, abuse control, support and pricing discipline. But these are execution challenges, not unsolved research problems.

India should not wait to win the frontier-model race before participating in the AI economy. The immediate opportunity is to win the inference layer for Indian developers, creators, startups, SMEs and enterprises. That layer is where usage happens, where revenue is recurring, where forex is leaking, and where a strong domestic platform can be built before moving upstream into proprietary models.

For most of software's history, writing code was the slow and expensive thing, so we organised around it. We split teams into backend, frontend, architects and platform: specialists who could each produce their slice faster than a generalist could. We worked in two- to three-week sprints, at the end of which we could evaluate the progress. All of it, the specialties and the long cycles, was a response to one constraint: coding was slow.

No longer. In my experience, the frontier AI is, for all practical purposes, a mid-to-expert full-stack developer. It will generate thousands of lines across the stack in a few minutes. So the bottleneck is no longer writing code. It's understanding it: holding the whole system in your head well enough to judge whether a change is sound, what it touches, and whether it should have been built at all.

If your engineering team is still carved into narrow lanes, AI-led development won't give you what you're hoping for.

Narrow ownership is where it breaks

Picture a backend developer who changes a service without fully grasping how it interacts with the frontend, the database and the systems downstream. Now hand that developer an AI agent. The agent will make changes whose implications across those other components the developer isn't equipped to see. The code looks fine in isolation and quietly breaks an assumption somewhere else.

This is made worse by how agentic coding behaves today: it builds more than you asked for. Some of that extra is genuinely useful. A lot of it isn't. Either way, someone has to understand the blast radius of every change, and a specialist who only sees one layer can't.

The cost argument

And it isn't even cheaper.

Say you adopt AI-led development on top of your existing structure. Your backend developer makes a clean, surgical change, exactly what was asked, and hands it off: to the frontend developer, to whoever owns the next module, to the reviewer. At each stop, the AI reads that same change again, a second time, a third time, once per handoff. And those re-reads aren't free, or even consistent: the model is non-deterministic, so how each developer frames the prompt shapes what comes back. Hand the same code to two people and you get two different readings of it. That's where the tokens go: rework and context thrash. A handoff misses a cross-component implication, something breaks, and now you're paying for debugging round-trips and for rebuilding context in every new session. The spend balloons, easily several times what the change should have cost.

And it's cumulative. To see how fast, I traced a single prompt to an agentic coding tool. Of the 626,538 input tokens it billed, only 67,306 were new. The other 559,232 were the same context, re-sent on every one of its 11 internal calls. This is for one developer and one prompt. Now extrapolate across developers and prompts, and the token count spirals.

Even though 80 to 90 percent of those tokens are cached, and cached tokens are cheap to process, when the numbers are huge it stops being a rounding error and becomes a line item. Across teams the cache benefit might not even accrue.

What the team should look like

The goal should be to reduce handoffs and promote as much co-development as possible. Before you push developers to adopt AI, change the shape of the team. In a first-class AI-led setup, I'd build around three people working in tight collaboration:

• A product owner who can define, clearly and concretely, what's worth building, and validate each piece the moment it lands.
• A full-stack architect who understands backend and frontend, keeps the system reliable and operable, and makes sure the AI's changes are sensible and clean. That last part matters more than it sounds. Even when you instruct the model to follow SOLID or DRY, it will ignore some of it. It is not unusual for AI to emit a single monolithic file thousands of lines long. Keeping the codebase clean is a continuous, deliberate job, not an afterthought.
• A tester who reviews changes thoroughly.

These three pair-program. They work closely and ship deliberately, with handoffs measured in hours, a day at most. A sprint shouldn't run longer than about three days, and you're delivering epics, not stories, because a single well-scoped story should now take minutes to implement, with the product owner reviewing and validating it almost as fast.

Code is cheap. Slow down anyway.

There's a thrill to watching AI produce a thousand lines in minutes, a real dopamine kick. And the agent feeds it. It keeps asking: should I build this next feature for you? The urge to say "yes, go" is strong, and that urge is the new failure mode.

So revisit the pace at which you churn out features. Take your time. There will be stretches where your developers don't have much to do, and that should be fine: idle hands are far cheaper than the wrong feature shipped fast. Your PMs and product owners, meanwhile, will need more time, not less, to decide what's actually worth building, because they are now the real constraint on the system.

And it isn't only your team that has to keep up. Your users do too. Every shipped change is something they have to absorb, and a firehose of new experiences is its own kind of harm, not a gift. So the constraint moves: from writing code to deciding what's worth writing.

That judgement, what to build, what to hold, what to never build at all, is the most important thing now, and it won't come from the agent. It will come from humans.

My perspective: possible for companies to build their own, but not feasible or worthwhile doing. Building software is one thing. Operating it securely, another.

The boom in cloud computing has those lessons. People moved to cloud not because they couldn't run their own infrastructure, but because they wanted to focus on running their business and not have the headache of running the infrastructure. So now the idea that companies will take on building their application layer? Unlikely.

Open source tells the same story. Fantastic enterprise software has been available for free for years. There you didn't even have to prompt to build. But enterprises needed reliability, accountability and assurance.

There is no cost advantage either. Building a scalable, highly available application costs the same or probably more than buying a SaaS subscription.

Sure, small custom internal apps and custom dashboards, where availability and resilience are not much of a requirement, companies might be able to cook up something and replace. But I don't think it's happening at an enterprise scale.

What I think actually happens

More vertical, highly specialised SaaS gets built. Motivated individuals and very small teams will be able to build sophisticated solutions. A $100 AI subscription enables that, because you get an expert in everything for that price. Use them judiciously, apply domain knowledge, and you can build a superb, highly specialised vertical SaaS product. It is something I am very focused on doing by building trackbooks.in.

For incumbent SaaS providers, it's likely to mean a lot more competition, therefore undercutting of their prices, and therefore adjustments to their valuations. And that will reflect in their stock prices.

Some SaaS might lose relevance altogether, because the underlying business processes they support are themselves changing. Think about project management tools like Jira, built around software development that used to take months and years, where traceability and documentation were key requirements. But if AI produces code in minutes, do you really need that level of traceability? Or shallow CRM tools: if I can get AI to orchestrate those workflows, do I need a sophisticated tool sitting in between?

That loss of relevance creates new opportunities. What kind of app do I need to track and manage AI-built software? Can we use AI to simplify workflows which were untouched before because the cost of building software for them was too high?

Likewise, small enterprises which operated using emails, Excel sheets and Word documents: can we create custom, sophisticated software for them? That is where the value will be, and the opportunities to create meaningful businesses.

More software also means more hosting. Given that making software got easier, there will be a lot more software out there, and the need to host it will further explode. This presents an opportunity for infrastructure specialists who can help host these mini apps.

So no, SaaS isn't dying. It's about to get a lot more competitive, a lot more specialised, and a lot more interesting.