Engineering with AI

Disclaimer: This blog was generated using AI with my recorded thoughts as reference. The ideas, examples, and opinions are mine. AI helped me convert them into a readable blog.

I think software engineering has changed forever.

There is no looking back. (this has been my preface for ever now🤣)

For a long time, we learned software engineering in a very specific way. We learned how to take a problem, collect requirements, design a system, write code, store data, and build an interface around it.

This was the normal path.

You understand the problem.
You decide what data to store.
You decide how the state changes.
You build the service layer.
You build the user interface.
You test it.
You deploy it.
You maintain it.

This is how most software was built.

But AI is changing this flow.

It is not only changing how fast we write code. It is changing how we should think.

Most software is state and state changes

Let us take a simple example.

A to-do application.

You need a place to store the list. You need a way to view the list. You need a way to add, edit, or delete an item.

That is software at a very basic level.

There is data.
There is state.
There are actions that change the state.
There is an interface to see and update that state.

The same idea applies to bigger systems too.

When you like a post on Instagram, it is a state change. Before the like, the system knows you have not liked it. After the like, the system stores that you have liked it.

When your phone syncs contacts from Gmail, two systems are talking to each other. One system has contact data. Another system asks for it, stores it, and keeps it updated.

This is service-to-service communication.

The scale may change. The architecture may change. The database may change. But the core idea is still similar.

Software stores state and changes state.

The old way was expensive

In the past, building software required a lot of hidden learning.

If you wanted to store secrets safely, you had to read documentation, blogs, PDFs, and best practices. You had to find people who had done it before.

If you wanted to containerise an application, you had to learn Docker and Kubernetes.

If you wanted to make an application resilient, you had to understand health checks, readiness probes, liveness probes, scaling, latency, and failure modes.

If you wanted to build rate limiting, you first had to understand why rate limiting exists.

Every new problem came with another learning curve.

This was not bad. This is how we became better engineers.

But it was slow.

The cost of making a decision was high. The cost of making a mistake was also high.

I remember working on a backup and disaster recovery product where I had to refactor logic to add a file into the system as part of a backup workflow. I spent almost a month on it.

That code never made it to the main branch.

Not because the effort was useless. But because the cost of accepting that change was too high for the organisation at that time.

This is one of the hard truths of engineering.

You can put your heart into a solution.
You can build something meaningful.
But the organisation still has to carry the risk of shipping it.

AI reduces the cost of trying

This is where AI changes the equation.

AI makes it much easier to build software.

Someone who does not know how to build a to-do application can now build one. Someone who does not know how to create a database schema can ask AI for help. Someone who does not know how to write an API can still get started.

This is a big shift.

It means software creation is becoming more open.

People who could not build tools before can now build tools for themselves. They may not need to depend on SaaS products for every small workflow. They can create simple software for their own needs.

The cost of trying has reduced.

That matters a lot.

Because when the cost of trying reduces, more people start experimenting.

And when more people experiment, we start seeing solutions in places where software was not previously economical.

Imagination becomes the limit

Think about agriculture.

For a long time, building software for agriculture had a high research and development cost. You needed to understand the domain. You needed to collect data. You needed to find the right users. You needed to build tools, test them, and improve them.

Now, a person can start faster.

They can ask AI about known problems in agriculture. They can read cited research. They can build a small tool to collect data. They can create a simple interface. They can even explore how a hardware device might collect useful information.

This does not solve everything.

But it changes the starting point.

The same applies to healthcare, finance, education, logistics, and many other domains.

There are many problems around us that have not been solved well. Not because people did not care. But because the cost of building and testing software was too high.

AI lowers that cost.

So now the important question is not only, “Can I build this?”

The better question is, “Is this worth building?”

The value of an engineer will change

AI can write code.

It can explain databases. It can suggest architectures. It can generate APIs. It can create user interfaces. It can help with tests, scripts, documentation, and debugging.

In many cases, it can explain software engineering concepts better than us.

But there is still something missing.

Judgement.

AI can give an answer. But we need to know whether the answer is right.

AI can suggest a solution. But we need to know whether it fits the problem.

AI can generate code. But we need to know whether that code should exist at all.

This is where engineers must grow.

The future engineer may not be valued only for knowing a programming language. The future engineer will be valued for knowing how to think about a problem.

What is the actual problem?
What context does AI need?
What should be solved first?
What can be broken into smaller parts?
What output should be trusted?
What needs to be verified?
What solution is simple enough to maintain?

These questions are becoming more important.

English may become the next programming language

I have heard people say that English will become the next programming language.

I agree with the idea.

But I also think it may go beyond English.

AI may become good enough that people can describe problems in Hindi, Kannada, Telugu, Tamil, or any language they are comfortable with.

That is powerful.

Because the barrier will not be syntax anymore.

The barrier will be clarity of thought.

Can you explain the problem clearly?
Can you give the right context?
Can you ask the right follow-up questions?
Can you judge the answer?
Can you turn a vague idea into smaller solvable parts?

This is the real skill.

Prompting is not just typing a question into a chat box.

Prompting is structured thinking.

We should think beyond software problems

Most of us are trained to think like software engineers.

We ask questions like:

Which database should I use?
Should this be REST or gRPC?
How do I scale this service?
How do I deploy this?
How do I make it resilient?

These are important questions.

But many of these problems have already been solved many times.

We know how to build databases.
We know how to build APIs.
We know how to build interfaces.
We know how to scale systems.
We know how to deploy software.

AI will make these things easier to access.

So maybe we should spend more time thinking about problems outside software engineering.

What is broken in an industry?
Where is data missing?
Where are people still using manual workarounds?
Where is software too expensive today?
Where can a small tool create a large impact?

This is where AI can help us convert non-software problems into software problems.

That is exciting.

The new engineering mindset

The new mindset is not “AI will do everything.”

That is too simple.

The new mindset is also not “AI is just a tool.”

That is also too simple.

AI is changing the way we move from thought to software.

Earlier, the journey was long.

Thought became requirements.
Requirements became design.
Design became code.
Code became product.

Now that journey is getting shorter.

A thought can become a prototype very quickly.

That means our thoughts matter more.

Weak thinking will create weak software faster.
Clear thinking will create useful software faster.

This is why engineers need to slow down before they speed up.

We need to ask better questions. We need to understand the domain. We need to know the user. We need to break problems down. We need to validate the output.

AI can help us move fast.

But it cannot decide what is meaningful for society.

At least not yet.

My recommendation

Learn how to use AI.

But more importantly, learn how to think with AI.

Do not start with code. Start with the problem.

Write down the context. Break the problem into smaller parts. Ask AI to explore options. Ask it to challenge your assumptions. Ask it to explain trade-offs. Then use your own judgement.

The future of software engineering may not belong to the person who writes the most code.

It may belong to the person who can find the right problem, explain it clearly, and use AI to build a meaningful solution.

That is how I think engineering with AI will change.

Not just in how we code.

But in how we think.