In 2026, I have hardly produced any code that was not generated by AI. Models like Claude Opus 4.8 and GPT 5.x, along with agent harnesses like Codex and Claude Code, made it extremely easy to generate production code.
So much so that people started throwing around ideas like “coding is a solved problem” and “code is cheap.” I disagree. I think we have simply moved a level of abstraction up. We are again at the crossroads of the never-ending debate between imperative and declarative programming.
But before we dive in, let us understand these two styles of writing code.
Imperative Programming 🔗
Most coding languages—C++, Java, JavaScript, and Python—are imperative in nature. You tell the system how to do it.
Consider writing a program in Python that reads a list of numbers and creates a new list with their square roots. We explain what to do (create a list of square roots) and how to do it (traverse each element, multiply it by itself, and store the result in a new list).
list_ = [1, 2, 3, 4, 5]
sqr_list = []
for l in list_:
sqr_list.append(l*l)
print(sqr_list)
In this example, we write instructions line by line without hiding any implementation details.
Declarative Programming 🔗
The biggest use case of declarative style is SQL. In declarative style, the language hides how (implementation details) and only expects what.
In the example below, we query an employee table for all employees with age below 25:
SELECT * FROM employee_table WHERE age <= 25
We have not told the database how to fetch from the table or which index to use first. That is the job of the query optimizer. We do not care about implementation details.
AI Prompts Are Declarative in Nature 🔗
If I need to write the Python program above with Claude, my prompt will be closer to SQL than to Python:
Take the list of numbers. Write a program to create a new list where elements are square roots of each element of the original list.
Again, in a declarative prompt we do not worry about implementation details. Agents are intelligent enough to gather context—that this should be written in Python, what looping strategy to use. We only worry about requirement specification.
Imperative and Declarative Are on a Spectrum 🔗
Even though we wrote the loop in Python imperatively, a lot of implementation details are still hidden. Memory management and array registers are abstracted away by the for loop. From the programmer’s perspective, calling a for loop is declarative.
No true programming is purely imperative or declarative today. Even SQL allows imperative steps through function calls or self-joins. It is the job of programmers and language designers to decide which implementation details to abstract away.
The Determinism Problem 🔗
There is an elephant in the room. I argued that AI prompts are declarative and that by generating code with agents, we are programming in a declarative style similar to SQL. But there is a significant caveat: the deterministic nature of SQL.
The declaration in a SQL query produces the same implementation steps for every database engine. A SELECT * FROM a_table performs the same set of instructions on every database.
But Write a loop in Python might generate a for loop or a while loop. This is the non-deterministic nature of AI token prediction. It is not a bug, but it leads to inconsistency in programs.
My thesis is not that AI replaces imperative coding with declarative style. In my opinion, it reshapes the spectrum, leaning more toward the declarative end of producing code. Unlike SQL, we do need to check the implementation details of LLM outputs.
While AI has come a long way from the initial days of hallucinations and unpredictability, LLMs still have those limitations. We can improve the quality of our declarative style of coding through some pre-implementation work:
- Adding skills — deterministic programs loaded on LLMs to perform specific tasks
- Adding clear and concise declarations — “write a for loop” rather than “write a loop”
- Strict code review, linters, and unit tests
Programming is still programming—declarative or imperative. Accountability lies with the developer and not with their tools. Understanding your codebase, LLM outputs, good and bad patterns will set apart programmers in the coming days. I am curious to see how much the spectrum will shift in the near future.