Remi's Realm [RR]

Shakespeare probably wasn’t thinking about LLMs when he wrote Hamlet (and his famous quote, “To be, or not to be”).

But here we are, facing our own version of that dilemma.

Do we write all our code ourselves? Or do we let AI generate everything?

In quantum mechanics, the concept of superposition allows a quantum system to exist in a combination of states until it is measured.

What if we could also move beyond two extremes when it comes to software development? (Superposition?)

What if we don’t have to choose between No Code and No AI?

What if the sweet spot lies somewhere in between?

Imagine a world where all cars in traffic have gas-powered engines…

Now imagine a world where all cars in traffic are electric vehicles (EVs)…

In the first hypothetical case, traffic would be even noisier than it already is, with more CO2 emissions and poorer air quality…

In the second hypothetical case, no power grid could handle such a load. If everyone charged their EVs, we wouldn’t have enough electricity left to run refrigerators and appliances, cook, or even see each other’s faces after sunset… We wouldn’t have enough electricity for our basic needs…

Four years ago, when we needed to buy our second car, I started exploring the EV market. Then I looked at gas-engine cars. I considered several factors, such as the availability of chargers on highways, how accessible they were, battery range, vehicle prices, government incentives, and my own range anxiety. After weighing these factors, we decided to go with a gas-engine car.

Such factors are still at play today. According to the International Energy Agency (IEA), electric cars accounted for about 5% of the global car fleet in 2025, while they represented 25% of new car sales worldwide. [1][2]

I find this an interesting point in the transition. People are choosing cars based on the factors I mentioned above, while the market continues to shift towards EVs. We have both EVs and gas-engine cars driving happily in traffic, although the transition is still underway.

Now, back to the topic of this blog post…

No Code vs. No AI in SDLC

Imagine a world where the entire codebase of a software project is written by human developers…

Now imagine a world where the entire codebase (including unit, integration, and E2E tests) of a software project is written or generated by LLMs.

In the first hypothetical case, software development and delivery would be much slower than they are today.

In the second hypothetical case, we would need unlimited tokens, hence unlimited money to finance token usage, and therefore unlimited computational power to run LLM models 24/7.

Neither of these scenarios sounds compelling or practical to me.

Recently, a software architect showed me a no-code mobile automation framework where all we had to do was provide text instructions, and an LLM would attempt to execute the mobile tests on its own—without generating or relying on any test scripts. When I saw this proof of concept, the architect had already consumed almost the entire monthly token allowance, yet the LLM-driven execution still couldn’t get past the mobile app’s login screen.

This would have been a great framework in a world where we had unlimited tokens… So, apparently, this wasn’t sitting in the “sweet spot” based on the real-world conditions and constraints we live in.

Now consider another mobile automation framework where no AI is used and the code is fully developed by human developers… This is another extreme on this spectrum, and it doesn’t sound appealing to me at all…

Then comes the million-dollar question… Where is the “sweet spot” for software development projects? Does it sit at 5%, similar to the share of EVs in the global car fleet?

Or more?

Or less?

We should start our exploration by looking at apps and software products that billions of digitally literate people around the world use every day…

Take mobile banking apps as an example… Do we log into the app, check balances, and make money transfers every day using roughly the same layout and workflow? Or do those pages show up under different menus every time we use them?

In other words, do these apps behave predictably, or do they behave randomly…?

• Do we get logged out while paying a bill?
• When transferring money between accounts, do we end up sending money internationally or making a Western Union (WU) transfer instead? No. Big no…
• When we check our account balance, does the app suddenly show someone else’s account?
• When paying a bill, does the app randomly change the payment amount or select a different payee?
• When we log in, do we sometimes see our account summary and other times find ourselves on a completely different page?

Of course, bugs can happen… But these are not the expected behaviors of a well-designed banking app.

As a matter of fact, such an experience would be chaotic and disastrous from a user experience point of view…

Now consider all the apps you use daily and see if they behave deterministically… (Excluding cases where an app goes through a major overhaul after a major version upgrade.)

If the software products we use and develop in today’s world behave deterministically, it means they can be scripted easily because they exhibit the same behavior every time (unless there’s a bug in the user flow).

When we run the same script over and over again, it doesn’t consume LLM tokens. It only uses local computational resources, which are always available as long as your local computer is up and running… However, asking an LLM to perform the same repetitive tasks over and over again consumes tokens for every single query…

This might be an unpopular opinion, but I think some things are better left scripted.

For example, asking an LLM about your Git status will cost you tokens. Whereas running “git status” command in the terminal is “free” (no token usage). From a token-economy point of view, it’s better to use the terminal and small scripts whenever and wherever we can…

Now, remember our million-dollar question… The sweet spot?

I think that, based on current real-world constraints, the sweet spot is where human developers work with LLMs to generate code that can then run repetitively and deterministically…

Is it 5%, like the share of EVs in the global car fleet?

I think it sits somewhere between 0% and 100%, depending on the conditions of the project…

Would the “sweet spot” shift over time along the No Code–No AI spectrum?

Certainly, yes…

What was the EV adoption rate 10 years ago? It started from a very small share of the market, and it has continued to grow over time. [2][3]

And it will likely continue to grow as technology improves, charging infrastructure expands, and EVs become a more practical choice for more people.

Could the adoption of LLMs in software development follow a similar path?

Let’s see how things evolve…

So, where will we find ourselves on the No Code–No AI spectrum in the coming years?

As token costs decrease, models become more capable, and open-source LLMs become easier to run locally, the balance will likely shift…

Tasks that are too expensive or unreliable to automate with LLMs today might become practical tomorrow. On the other hand, some tasks may always be better handled by traditional scripts.

I don’t think there is a universal sweet spot for every software project. It depends on the project, the task, the available tools, and the constraints we work under.

The sweet spot isn’t a fixed point on the spectrum… It’s a moving target.

And perhaps the real question isn’t whether we should code or let AI code for us, but when should we use each approach, and where should we position ourselves on the No Code–No AI spectrum?

I think our position on this spectrum will keep shifting in the coming years as AI models become more capable, token costs change, and new tools and approaches emerge…

What seems impractical today might become perfectly reasonable tomorrow. And the sweet spot we find today might not be the same one we’ll find a few years from now…

References

[1] International Energy Agency (IEA). (2026). Global EV Outlook 2026: Trends in electric cars. Paris: IEA. https://www.iea.org/reports/global-ev-outlook-2026/trends-in-electric-cars

[2] Our World in Data. (2026). Share of cars currently in use that are electric, 2010–2025. Data source: International Energy Agency, Global EV Outlook 2026. https://ourworldindata.org/grapher/share-car-stocks-electric

[3] Our World in Data. (2026). Share of new cars sold that are electric, 2010–2025. Data source: International Energy Agency, Global EV Outlook 2026. https://ourworldindata.org/grapher/electric-car-sales-share

A Note on Collaboration: In the spirit of finding the right balance between human insight and AI tools, an LLM was used in a supporting role to assist with grammar and word choice, as English is my second language. All original concepts, perspectives, and core writing remain 100% my own.

Abbreviations

Here is the list of abbreviations used throughout your blog post, formatted cleanly so you can copy and paste it directly at the end:

• AI: Artificial Intelligence
• CO₂: Carbon Dioxide
• E2E: End-to-End (Testing)
• EV: Electric Vehicle
• IEA: International Energy Agency
• LLM: Large Language Model
• POC: Proof of Concept
• SDLC: Software Development Life Cycle
• WU: Western Union