From n8n workflows to AI coding agents, from Claude to OpenRouter, and from managing a team to teaching it to think. Apparently, I had a few things to learn before writing this post.

My last blog post was in February.

It’s October now.

Eight months.

I know some people take a break from blogging to travel, relax, spend time with family, or pursue their hobbies.

I took a break because the technology I was trying to write about kept evolving faster than I could finish writing about it.

Every time I thought, “Okay, this is worth writing about,” something new appeared.

A new model. A new coding agent. A new workflow. A new open-source release. A new framework promising to change everything we do as engineers.

By the time I understood one thing well enough to write about it, three other things had changed.

At some point, I realized that if I continued waiting for the AI ecosystem to settle down before writing about it, my next blog post would probably be published by an AI agent after I retired.

So, here I am.

I’m back!

And, as it turns out, I have quite a bit to talk about.

Over the past eight months, AI has evolved at a ridiculous pace.

And when I say ridiculous, I mean that keeping up with AI sometimes feels like working on a production incident where every time you fix one issue, three new tickets appear.

Except nobody knows who created the tickets, the documentation is already outdated, and the next release is scheduled for tomorrow.

Welcome to AI engineering.

Last year, my approach to AI was primarily centered around LLMs and automation workflows. I spent a lot of time exploring n8n, connecting models to tools, designing workflows, and figuring out how to automate repetitive tasks.

It was exciting because we could take a process that required several manual steps, connect a few services, introduce an LLM, and suddenly have something that looked remarkably intelligent.

Then came the next phase.

Claude Code Changed the Way I Looked at AI

Toward the end of last year, Claude Code, particularly with Claude Opus 4.5 and Sonnet 4.5, significantly changed how I approached engineering work.

Until then, I had spent considerable time thinking about how to connect LLMs to workflows and make them useful.

Claude Code made me think differently.

What if AI didn’t just respond to prompts or execute predefined workflows?

What if it could explore an entire repository, understand the codebase, investigate an issue, plan a solution, modify multiple files, run tests, inspect failures, and continue working until it had a reasonable implementation?

What if the workflow itself could be driven by an agent that understood the task rather than a fixed sequence of automation nodes?

That was a turning point for me.

I started seeing AI not merely as a tool that helped me write code, but as something that could participate in the engineering process itself.

The shift from asking AI to write code to letting AI work through an engineering task was one of the biggest changes in my personal journey.

Of course, the engineer still needs to review the work, validate the implementation, understand the architectural implications, and take responsibility for the result.

But the way we get there has changed dramatically.

And once you experience that shift, it’s difficult to go back to treating AI as just another chatbot.

I still believe workflow automation tools such as n8n are incredibly useful.

They are excellent for connecting systems, triggering events, orchestrating business processes, integrating APIs, and automating predictable workflows.

But I’ve learned that not every problem should be solved with a workflow.

Some problems need a workflow.

Some need an agent.

Some need a combination of both.

And some need an experienced engineer to look at the proposed solution and ask, “Why on earth are we building this?”

That last capability remains surprisingly difficult to automate.

My approach has evolved from building LLM-powered workflows toward using coding agents for much of my engineering work.

Instead of manually directing every small implementation step, I can give an agent a well-defined task, provide the relevant context, let it investigate the repository, and review the resulting changes.

This doesn’t eliminate engineering work. It changes where the engineering effort goes.

Less time can be spent on repetitive implementation. More time can be invested in understanding requirements, reviewing architecture, identifying edge cases, validating security, and making decisions.

At least, that’s the goal.

Sometimes the agent does everything beautifully.

Sometimes it confidently rewrites half the application to fix a typo.

And sometimes you spend longer explaining why its proposed solution is wrong than you would have spent writing the code yourself.

AI engineering is wonderful.

AI engineering is also an excellent way to develop patience.

For a while, we relied heavily on Claude for our engineering workflows.

There was a good reason for that. The models were capable, the coding experience was productive, and Claude Code made it easier to tackle complex implementation tasks.

But relying too heavily on one provider creates a problem.

What happens when that provider becomes unavailable, experiences degraded performance, or imposes limits that interrupt your workflow?

Your engineering productivity can suddenly depend on something outside your control.

It’s a little ironic.

We were using AI to eliminate bottlenecks in software development, only to discover that our AI provider could become a bottleneck itself.

Eventually, our organization began moving toward OpenRouter, the same platform I’d been using personally throughout 2024–2025 and had discussed extensively on my blog and other platforms. Interestingly, we’re now returning to it at the organizational level, especially following Stripe’s acquisition of OpenRouter in August 2026, while leveraging different models for different tasks.

This wasn’t simply about replacing one model with another. It was about giving ourselves more flexibility.

Different models have different strengths. Some are particularly useful for coding, others for reasoning, and others for faster, more economical tasks.

Having access to multiple models gives us more options when choosing the right tool for a particular job.

It also helps reduce dependence on a single provider.

The lesson I learned is that model flexibility is not just a cost optimization strategy. It is an engineering resilience strategy.

We should apply the same thinking to AI that we already apply to infrastructure.

We don’t want a single point of failure in production, so why should our entire engineering workflow depend on one model being available at all times?

That doesn’t mean every organization needs to route every request through multiple providers. It means we should understand our dependencies, evaluate the risks, and design our workflows accordingly.

With 15+ years of experience, I’ve built and scaled digital products that power businesses globally. From PHP, Laravel, Angular, Cloud, AI to building high-performance eCommerce and SaaS solutions, I specialize in solving real-world tech challenges.

Another reason I struggled to keep up with AI over the past eight months is that the progress hasn’t been limited to proprietary models.

Open-weight models have also improved significantly.

The distinction between proprietary and open-weight models matters, but the conversation is no longer as simple as saying one category is good and the other is bad.

Different models offer different trade-offs in reasoning, coding, speed, cost, context length, customization, deployment flexibility, and data control.

For some tasks, a smaller model may be more than sufficient.

For others, a more capable reasoning model can make a meaningful difference.

And for organizations with specific privacy or infrastructure requirements, the ability to run and customize an open-weight model can be particularly valuable.

I’ve increasingly come to see model selection as an engineering decision rather than a loyalty decision.

You don’t need to marry a model.

You need to know when to use it.

The best model for a task is the one that delivers the required result within the relevant constraints.

Sometimes that means using a frontier proprietary model.

Sometimes it means using an open-weight model.

Sometimes it means using a cheaper model for the initial investigation and a stronger one for the difficult reasoning.

And sometimes it means admitting that no model has enough context to solve the problem reliably without further investigation.

The important thing is to understand the differences rather than blindly following whichever model is trending on social media this week.

Although, admittedly, keeping up with those trends has become a full-time job of its own.

These days, I’ve been using Pi and Pi.dev coding-agent workflows for much of my engineering work.

My focus has shifted toward letting coding agents help with the entire implementation process, rather than treating AI as a tool for isolated coding questions.

The agent can investigate a codebase, understand a ticket, explore relevant files, implement changes, run commands, inspect failures, and help prepare the resulting changes for review.

This is where I see a significant opportunity for engineering teams.

We can move away from measuring productivity purely by how quickly someone types code and toward measuring how effectively they turn requirements into reliable, tested, maintainable solutions.

But there is an important catch.

A coding agent can accelerate your engineering process. It cannot compensate indefinitely for unclear requirements, poor architecture, missing context, or a lack of engineering judgment.

If you give an agent an ambiguous requirement, it may produce an impressive implementation of the wrong thing.

If you ask it to modify a system without explaining important constraints, it may make assumptions that are technically reasonable but operationally dangerous.

If you don’t review its changes, you may discover the consequences much later.

The quality of the result still depends on the quality of the thinking that guides the work.

This is why I have become increasingly interested in the relationship between AI, engineering practices, and leadership.

And that brings me to the part of my journey that has been even more challenging than learning new tools.

I’ve been leading teams for around ten years.

Until recently, my approach to leadership was built around mentoring people, delegating tasks, managing delivery, helping team members solve technical problems, and ensuring that work was completed.

Those are all important responsibilities.

But my understanding of leadership has been changing.

After my achievements at work, I was promoted into a role where I continued to work as an engineer alongside the team I was leading.

That created a different challenge.

I was no longer simply managing people and distributing tasks. I was working alongside people who had been my peers, while also being responsible for technical direction, decisions, and delivery.

When you move from being a teammate to leading the same team, the dynamics change.

You cannot assume that people will automatically understand your expectations because you now have a different title.

You cannot expect everyone to approach problems the way you do.

And you cannot build a high-performing team simply by giving people tickets and checking whether they have completed them.

I found myself facing questions that were less about technology and more about people.

How do I help the team understand my reasoning?

How do I encourage people to question decisions rather than simply execute instructions?

How do I build a team that can make good decisions independently while remaining aligned on the overall direction?

How do I ensure that everyone understands the purpose of the work, not just the task assigned to them?

I had been leading teams for years, but I realized there was another level of leadership I needed to develop.

And one conversation helped me see it differently.

My manager, Frank Hoffman, helped me look at leadership from a different perspective.

The idea was simple, but the implications were significant.

Leadership isn’t just about mentoring people, delegating tasks, and managing delivery. It is about developing a team that can think critically, question decisions, and understand the reasoning behind its work.

For years, I had focused on asking why.

Why are we implementing this solution?

Why are we choosing this architecture?

Why are we making this change?

Why are we following this process?

I had learned to question decisions rather than accept them at face value.

But I began to realize that it wasn’t enough for me to think that way.

I needed to help the entire team develop the same habit.

I needed team members to ask themselves why before starting a task.

Why does this requirement exist?

Why is this the right approach?

Why are we modifying this component instead of another?

Why is this implementation better than the alternatives?

Why are we introducing this complexity?

And perhaps the most important question of all:

Why are we doing this at all?

When engineers understand the reasoning behind their work, they can identify problems earlier, challenge incorrect assumptions, and make better decisions without waiting for someone else to guide every step.

That is a different level of team maturity.

It doesn’t mean everyone must agree with the leader on everything. Quite the opposite.

A strong team should be able to challenge assumptions, present evidence, and disagree constructively.

The goal is not to make everyone think identically.

The goal is to build a shared way of reasoning, a common understanding of objectives, and consistent standards for making decisions.

I want the team to understand how I approach problems well enough that they can independently evaluate decisions, anticipate risks, and explain their reasoning.

That gives me more room to focus on larger architectural concerns, strategic priorities, and the team’s overall growth.

It also forces me to become more deliberate about how I think and communicate.

Because if I cannot explain why a decision makes sense, I probably need to examine that decision more carefully myself.

Apparently, leadership comes with its own debugging process.

And, just like software debugging, the root cause is not always where you initially expect it to be.

Back in 2015, when I was working at Potenz, our CEO, Frankie Russo, gave me a book called The Art of Why.

That book influenced the way I approached problems.

I began questioning decisions more deliberately and trying to understand the reasoning behind the things I worked on.

Instead of accepting an instruction simply because someone had given it, I wanted to understand the purpose.

Over the years, that habit became part of how I approached engineering.

But now I see another dimension to it.

It is not enough for me to question why.

I need to help the people I work with develop the same discipline.

If I make a technical decision, the team should understand the reasoning.

If a team member proposes an implementation, I should expect them to explain why it is appropriate.

If we choose one solution over another, we should understand the trade-offs.

And if something doesn’t make sense, we should be comfortable asking questions before committing to the work.

This is particularly important in the age of AI.

AI makes it easier to generate solutions. It also makes it easier to generate solutions without fully understanding the problem.

An agent can produce hundreds of lines of code in minutes. But if nobody questions why those lines are needed, we may simply be accelerating the production of unnecessary complexity.

The same applies to human teams.

When people understand why, they become more than task executors. They become engineers who can reason, challenge assumptions, and take ownership of outcomes.

I’m still working on building that culture within my team.

It is an ongoing process, and I consider it one of the most valuable opportunities for growth in my career.

Just when I thought I had enough topics to write about, the digital world provided another reminder of why all this matters.

On October 21, 2026, the PHP development team released emergency security updates addressing two critical vulnerabilities associated with PHP2Shell.

According to the official PHP advisory, the vulnerabilities could allow unauthenticated remote code execution under affected conditions. Wiz Research reported that the underlying weaknesses had existed for more than a decade and demonstrated how they could be exploited against widely used PHP applications.

The incident triggered an urgent response across the technology ecosystem.

The UK’s National Cyber Security Centre advised organizations to identify affected systems and apply the available fixes. Reuters and The Guardian reported precautionary service shutdowns as organizations worked to protect vulnerable systems.

Cloudflare reported millions of attempted exploits and described how it prepared and deployed additional web application firewall protections.

For technical details, see the ⁠official PHP advisory, ⁠Wiz Research’s PHP2Shell analysis, and ⁠Cloudflare’s explanation of its protections.

A critical distinction is worth making here: attempted exploitation does not automatically mean successful compromise, and precautionary shutdowns do not necessarily indicate that a system was hacked.

Nevertheless, the incident demonstrated how quickly a vulnerability in a widely deployed technology can become an operational emergency.

And the AI component makes it even more interesting.

Researchers used advanced AI models alongside traditional security research tools to investigate the vulnerabilities, analyze complex code paths, and develop working exploit chains.

The flaws had existed for years.

The ability to discover and investigate them is evolving.

That is the part that deserves our attention.

AI is changing not only how we build software, but also how we discover the weaknesses that threaten it.

The PHP2Shell incident reinforces something that I believe every engineer should understand.

AI is becoming a force multiplier for both defenders and attackers.

A capable model can help developers understand unfamiliar code, identify suspicious patterns, investigate memory-safety issues, and analyze potential vulnerabilities.

The same capabilities can assist with exploit research.

That doesn’t mean every AI-generated finding is correct or that every vulnerability can now be exploited automatically. Human expertise, experimentation, validation, and appropriate tools remain essential.

But the barrier to investigating certain complex security problems may be getting lower.

For defenders, this creates an opportunity to identify and fix weaknesses earlier.

For attackers, it creates the possibility of investigating targets faster and scaling certain activities.

For engineering teams, it changes the expectations around security.

We can no longer assume that a mature codebase is safe simply because it has existed for years.

We cannot assume that passing tests prove the absence of vulnerabilities.

And we cannot assume that using AI to generate code automatically makes our applications more secure.

AI can accelerate development, but it can also accelerate mistakes.

This is why we need engineers who understand their technology deeply enough to use AI intelligently, challenge its output, and validate the results.

A generated patch is not proof of security.

A successful deployment is not proof that an attacker never compromised the system.

And a model’s confidence is not evidence that its answer is correct.

The engineering process still matters.

Perhaps more than ever.

One lesson I have taken from my experience with different models is that we should stop treating AI model selection as a popularity contest.

Different models have different strengths.

Some are well suited to routine coding tasks. Others may perform better on complex reasoning, repository exploration, or difficult debugging.

Open-weight and proprietary models offer different trade-offs in capability, cost, customization, deployment flexibility, and data handling.

Neither category is automatically superior.

For everyday work, a smaller and less expensive model may be perfectly adequate.

For a complicated security investigation, an architectural decision, or a difficult debugging task, a stronger reasoning model may be worth the additional cost.

The important thing is to match the model to the problem.

Do not automatically use the most expensive model for everything.

Do not automatically choose the cheapest model for everything either.

And do not assume that the model you used successfully yesterday is necessarily the best option for every task today.

Evaluate the results.

Understand the limitations.

Validate the output.

And make sure your engineering workflow doesn’t depend entirely on one provider.

The AI ecosystem is evolving too quickly for blind loyalty to make sense.

Looking at the pace of AI development, I expect the next few years to bring significant changes to software engineering and cybersecurity.

Coding agents will continue to improve. Open-weight models will continue to evolve. Organizations will explore increasingly sophisticated AI workflows.

The way we build, test, deploy, and maintain software may look very different by the end of 2028.

Quantum computing also raises important longer-term questions about the cryptographic algorithms used to protect digital systems.

A sufficiently powerful, fault-tolerant quantum computer could threaten widely used public-key cryptography, although that does not mean all encryption will suddenly become useless or that such a capability is already available at the necessary scale.

The transition toward post-quantum cryptography is already an important consideration for organizations protecting sensitive information over long periods.

When we combine advances in AI with changes in computing and cryptography, the message is clear: the assumptions behind today’s technology will not remain valid forever.

We need to keep learning.

We need to prepare our systems for change.

And we need to ensure that our engineering practices evolve alongside our tools.

The biggest risk is not simply that AI will become more capable.

It is that our ability to adapt may not keep pace with it.

So, why am I finally writing this post now?

Partly because I have a lot to share.

Partly because the AI ecosystem has changed so much that I feel compelled to document my journey.

And partly because I finally had some time to step back and organize my thoughts.

I took four days of leave around Dussehra, which gave me a total of nine days away from work.

For once, I had some breathing room to reflect, spend time on personal priorities, and put a little order into my personal and professional life.

It also gave me an opportunity to look back at the last eight months.

I realized that I had spent so much time learning new technologies, experimenting with AI tools, adapting my engineering workflow, and growing into my leadership responsibilities that I had neglected something I genuinely enjoy: sharing what I learn.

I’ve seen messages from people reaching out through Discord, Slack, and WhatsApp.

Some were asking what I was working on. Others wanted to discuss AI tools, coding agents, and the changes happening in engineering.

I saw those messages, and I wanted to respond properly.

But every time I thought about writing a post, something else came up.

Then another model was released.

Then another tool changed the workflow.

Then another idea seemed worth exploring.

Eventually, the easiest way to keep up with AI was apparently to stop writing about it.

Brilliant strategy.

Terrible blogging strategy.

So, I’m changing that.

I may not be able to document every new model, every framework, or every development in the AI ecosystem. Nobody can keep up with everything anymore.

But I can share what I learn, what I experiment with, what works, what doesn’t, and how these changes affect my work and life.

I want to write more about technology, engineering, AI, leadership, and the lessons I learn along the way.

Not because I have everything figured out, but because sharing the learning process is valuable in itself.

Over the past eight months, AI has changed how I approach engineering.

I moved from experimenting heavily with LLMs and n8n workflows toward using coding agents for much of my implementation work.

Claude Code helped me see what agentic engineering could become. OpenRouter and access to different models helped me think more seriously about flexibility and resilience. Pi has become part of how I approach everyday engineering tasks.

At the same time, my understanding of leadership has continued to evolve.

I’ve learned that leading a team isn’t simply about mentoring people, assigning tasks, and ensuring delivery.

It is about helping people develop the ability to think critically, question assumptions, understand why decisions are made, and take ownership of outcomes.

The PHP2Shell incident has reinforced how important those capabilities will be as AI advances.

We need engineers who can build with AI, investigate with AI, secure systems with AI, and recognize when AI is wrong.

We need teams that can reason independently while working toward shared goals.

And we need leaders who can help people navigate uncertainty without pretending to have every answer.

I’m still learning all of this.

The technology is evolving. My engineering practices are evolving. My approach to leadership is evolving.

And, apparently, my blogging habits are evolving too.

Eight months is a long time to disappear from your own blog.

Let’s see if I can do better this time.

I’ll try to share more regularly from now on—new technologies I’m exploring, things I’m learning at work, experiences from my personal life, and lessons from the journey.

If you’ve been following my posts, thank you for your patience and support.

If you’ve reached out through Discord, Slack, or WhatsApp over these past months, thank you as well. I may have been quiet, but I haven’t stopped learning or experimenting.

I’m back, and I hope you’ll continue following along.

And if my next post takes another eight months, you have my permission to send an AI agent to investigate the root cause.

Just make sure it doesn’t rewrite my entire blog to fix the issue.

Until next time.

— Arun