Mohit Rawat

Tradeoffs when AI writes the code

I wanted to create an app for practicing AI concepts for myself. For best results, I wanted to write the code without AI assistance. I struggled a lot with the process:

  1. I didn’t remember the syntax itself, and it took some time to get used to it.
  2. The process was very slow, and I wanted to move fast. So I asked a coding agent to do the boilerplate work, and so many changes were done with one prompt that I couldn’t read every line anymore. It felt pointless writing any code by typing due to the sheer speed of code generation.

Which raises the question of what the future holds. Since I don’t know the answer yet, I think asking more questions without answers may help with the direction.

What I do at work now

At work, almost all my code is generated using AI coding agents. And the code review is done with another agent. I have tried unsuccessfully to do code review by reading, and it’s almost impossible to keep up with the generation.

What I focus on is coming to a shared understanding of the scope of the feature within the chat session, understanding the pros and cons of different approaches, and the priority of what should be built first and released.

Is code the answer to every request?

There are software factories coming up that generate code for a feature request or an issue. Maybe the time is not far off when every request raised by Customer Success teams or other teams results in a release. Or maybe in the future, just do another AI-driven release whenever there is an incident (assuming code + GitOps + observability can cover that incident). Next it will be for Sev1, Sev2 or a release for any alert. And then for any error. Which raises the question: Is writing code the answer to every question? Who deletes the code and the features? Should code be written for human understanding or agent convenience?

Who deletes code?

For code deletion so far, once the code is in production, I am not really thinking of deleting anything anymore. Before release, I still decide what goes there. For example, workflows are so common that I had to decide what the best way to build one was.

  1. Using standard queues + consumers + producers. A standard approach that I have used for a long time.
  2. Using frameworks like Mastra or Inngest or something similar.
  3. Building one using AI, since why not. It’s easy to write code, and if I can build one on my abstractions, I can reuse it everywhere.

I ended up going live with option 1 and deleting the implementations for options 2 and 3. I deleted option 2 since I didn’t like the abstractions and option 3 since I didn’t like the implementation. It was too complex, and I had to read the implementation to steer it to a better one. It was taking time, and working on different features at the same time means less attention and less patience for a particular task, especially when there are options.

The problem with the implementation for me was that in this particular case and in general as well, the complexity comes from building the perfect solution on day one, using generics, decorators, callbacks, and perfect abstractions from day one itself. I generally prefer simple code and increase complexity when needed. So this is another reason, along with the number of lines, why I can’t read all the code for understanding.

Alerts that remain

The other part is on the production release side. If AI can write perfect code (whatever that is), then there is minimal need for code review. And less need for alerts and monitoring and observability.

The alerts that I think of today are of these three types: The alerts can be related to third-party integrations, logic, or infra.

  1. For me, I had faced dependencies on Meta APIs, for example, which get rate limited. So one decision here is what an agent should do for that alert. Should it have backups like using scrapers or something else? Which I ended up doing later.
  2. Logic-related: There can be alerts due to expectations not matching the reality of the search. A user wanted to search for cat pics on the platform with text search. Amongst cat images, there were isolated cases of dog images which were standing out. So if a user sees an image of a dog as “cat” is in the caption, would that be the right solution? Would showing the metadata for what matched in the search be the right solution? The other example is whether a creative can be reused across regions. For example, can a video creative in India with a model’s face be reused in the Middle East or Singapore? The answer depends on the product but also on the person making the decision.
  3. For infra alerts, I spend less time, as managed platforms handle most of the work. So not going into a lot of details here.

Tradeoffs

There are three types of tradeoffs that I deal with.

  1. Third-party integrations: which can partly be solved through having multiple integrations or options.
  2. Logic-related: where the same output can be interpreted differently by two different users. Which is probably why personalised solutions seem more popular than typical SaaS solutions. Like Claude Code, Codex, Hermes, OpenClaw.
  3. Infra-related: which can partly be solved through redundancy. Run replicas in different regions, multiple clouds, etc. Focus more on disaster recovery solutions. This results in either higher costs or better pooling at scale.

Open questions

So the open questions for me are:

  1. If resiliency is a cost problem, is everything a cost optimisation?
  2. How do you build a personalised SaaS solution today and what would it look like?
  3. And an open question from earlier: is new code the answer to every problem?
  4. If AI writes the code, and AI writes the tests, and I don’t read any of it, what do the tests prove? Are only user acceptance tests relevant in the long term?