Essays on Jerry Mannel Reghunadh

AI Makes Development Easy, But Engineering Is Still Hard

Wed, 20 May 2026 21:07:00 -0500

Software engineering is hard.

Even with AI, it is hard.

But software development? That is becoming easy.

With today’s agentic tools, applications we once shelved for lack of time can now be built in an afternoon. “Vibe-coding” a frontend and wiring it up to a backend takes hours. Your friends and team will try it, and they won’t care if it crashes, leaks data, or looks unpolished. Kudos to everyone making their ideas a reality. It’s a great start.

But let’s not confuse software development with software engineering. What you have built is a working prototype. At best a high school project.

Software engineering is hard because of what comes after the prototype. The engineering feat begins when you have to solve for:

• multi-tenancy and access control
• making it globally available
• data security - in transit and at rest
• packaging, deployment, monitoring

AI can suggest architectures, but the right decision doesn’t come from a prompt. It comes from intuition and judgement.

The intuition and judgement that you honed by trial and error. It comes from the scars of tough lessons. It comes from the baggy eyes from late-night debugging sessions. It comes from the euphoria of fixing a critical bug.

AI can assist in ideation. It can debate with you on whether you should use a document DB or a relational DB (btw, the answer is document DB 99% of the time 😀). But choosing the path forward, that requires weighing in the pros and the cons of each option.

You have to think about the user personas and the context of the business. You have to think about the data you are processing and the SLAs you need to target. You have to think about the business impact of each option. That translation of business reality into technical architecture is where the engineering happens.

With AI, generating a feature takes 10 minutes. Deciding whether that feature should exist is the hard part. The prompt is easy; the judgement is hard.

Julien Bek, a partner at Sequoia Capital, noted in his article “Services: The New Software” https://sequoiacap.com/article/services-the-new-software/:

Writing code is mostly intelligence. Knowing what to build next is judgement.

This isn’t a comforting claim that engineering roles are completely safe from automation.

They aren’t.

Bek also points out that as AI systems accumulate proprietary data on what good judgement looks like, the frontier will shift. The time and effort spent on basic code generation is collapsing, and it will continue to do so.

The only logical response is to intentionally build your judgement. You need to understand the patterns, signals, and architectural trade-offs. Use AI to speed up your execution and expose you to patterns you might miss, but take the time to reflect on why a solution works.

I’d rather see 20 unfinished, highly experimental projects on your GitHub than one perfectly vibe-coded app that you don’t actually understand.

Build your intuition. Focus on judgement.

Show off your scars!

✌🏽

./J

From "Half-Stack" to Full-Value: Owning Your Deployment Pipeline

Thu, 02 Oct 2025 16:41:10 -0500

I recently had the pleasure of speaking at the Commit Your Code conference, where I presented my talk, “The Modern Full-Stack: Owning Your Deployment Pipeline.” The core idea was to challenge our definition of what it means to be a “full-stack” developer in today’s world.

For too long, we’ve defined full-stack as proficiency in front-end and back-end development. But I’d argue that this leaves a massive gap. If you write code but have no visibility or ownership over how it gets to users, you are not full-stack, you are “half-stack”.

The modern full-stack engineer needs to be concerned with integration, deployment, and infrastructure. When we own the pipeline, we build better software and deliver value more efficiently.

What’s Holding Us Back?

If owning the pipeline is so important, why isn’t everyone doing it? It usually boils down to fear and organizational silos.

Fear of the Unknown

Many developers are comfortable in their IDEs, but the idea of a “terminal” can be intimidating. We’re dealing with configurations, not just code. This leads to crippling “what-if” scenarios: -

What if I break production?
What if I take down the whole system?

Organizational Silos

In many companies, there’s a cultural barrier, what I call “The Wall of ‘Not My Job’”. Responsibilities are so divided that simple actions get stuck behind a wall of bureaucracy and tickets. I get that sometimes, we need to have this layer. But why do that during the development and testing phases? This mindset prevents developers from taking the ownership necessary to innovate.

The Core Principles

Overcoming these barriers starts with understanding the core principles that enable pipeline ownership. These aren’t magic; they are a set of practices and tools designed to make deployments safe, repeatable, and efficient.

1. Continuous Integration (CI)

CI is the practice of automating builds and tests every time a developer pushes code to a central repository. This helps find and fix bugs early.

2. Continuous Delivery/Deployment (CD)

CD automates the entire software release process, enabling consistent and reliable deployments. This is how you can deliver new features to users faster and with less risk.

3. Infrastructure as Code (IaC)

IaC is the practice of defining and managing your infrastructure (servers, networks, databases) using code instead of manual configuration. This is the key to creating consistent and reproducible environments automatically.

4. Observability

Observability is about instrumenting your application to collect detailed logs, metrics, and traces. It allows you to ask deep questions about your system’s behavior and understand why an issue is happening, not just what is happening.

Understanding the configurations

Since most configurations are written in plain text, you can simply open the files and read through them.


Sample dockerfile	Sample Kubernetes deployment yaml file

If you read through these files, it’s quite easy to understand what the configuration file is trying to achieve.

Then the question is as developers are we supposed to memorize all these configurations? Absolutely not! You need to build these configurations once, the right way and then templatize it for the next app.

Here’s a sample templatized kubernetes deployment yaml file that I keep. I replace the sections that starts and ends with --.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: --app-name--
  namespace: --namespace--
spec:
  replicas: 1
  selector:
    matchLabels:
      app: --app-name--
  template:
    metadata:
      labels:
        app: --app-name--
    spec:
      containers:
        - name: --app-name--
          image: --image--
          ports:
            - containerPort: --port--

Best Practices

Adopting the tools is one thing, but truly owning your deployment pipeline requires a shift in mindset. It’s about cultivating habits that prioritize stability, security, and speed. Here are four essential best practices to guide you on this journey.

Best Practices

Shift Security Left.

For decades, we’ve treated security as the final boss battle of a project. Developers would code for months, then toss the finished product over the wall to a security team, hoping it would pass the review. This “gatekeeper” model is slow, inefficient, and creates an adversarial relationship.

The modern approach is to “shift security left,” embedding it into the earliest stages of development. Instead of a final inspection, security becomes a continuous practice. Automated tools can be integrated directly into your CI pipeline to scan for vulnerabilities on every single commit.

By doing this, you get feedback in minutes, not months. You learn if you’ve introduced a vulnerability while the code is still fresh in your mind, transforming security from a roadblock into a real-time guideline for writing safer code.

Make Small, Reversible Changes.

The goal of a powerful deployment pipeline is not to make it easier to ship massive, high-stakes changes. It’s the exact opposite: the goal is to make deployments so frequent, small, and routine that they become boring.

Big-bang releases are terrifying because they bundle hundreds of changes, making it impossible to pinpoint the cause of a problem. The modern full-stack developer works in small, incremental steps. Every pull request should represent a minimal, logical unit of work.

Crucially, every change must be easily reversible. While a git revert is a good start, a far more powerful technique is to wrap new features in feature flags. If a new feature starts causing problems in production, you don’t need to roll back the deployment and kick off a frantic debugging session. You simply flip a switch, deactivating the feature for users while you investigate the issue in a low-stress environment.

Use Blueprints, Not Sculptures.

Think about how we’ve traditionally managed servers. We treat them like delicate sculptures. Each one is a unique masterpiece, handcrafted over time with manual package installations, SSH sessions, and tweaked configuration files. If one of these “sculptures” breaks, it’s a catastrophe, and rebuilding it from memory is a nightmare.

This is where Infrastructure as Code (IaC) changes the game. We stop being artisans and start being architects. Our infrastructure is no longer a sculpture; it’s built from a blueprint.

Our Terraform files, CloudFormation templates, and Dockerfiles become the single source of truth.

Need a new staging environment? Run the blueprint.
A production server fails? Automation terminates it and spins up a perfect, identical replacement from the blueprint in minutes.

This approach, sometimes referred to as treating servers like “cattle, not pets,” guarantees consistency, eliminates configuration drift, and makes disaster recovery a fast, predictable, and automated process.

Build for Observability.

Your responsibility as an engineer doesn’t end when your code is deployed. It ends when you can verify that your feature is working as intended for real users in the chaos of production.

This is why we must build for observability. It’s the practice of instrumenting our applications so they emit signals about their health and performance. As you code a new feature, you should constantly be asking: “How will I know this is working? How will I know if it’s failing?”

This means going beyond simple print statements. It means:

Structured Logs: Writing logs in a machine-readable format (like JSON) that can be easily searched and filtered.
Key Metrics: Tracking the “golden signals” for your feature—request rate, error rate, and latency.
Distributed Tracing: Creating a complete picture of how a request flows through your various microservices.

Shipping a feature without the ability to observe it is like launching a satellite without any instruments. It might be up there, but you have no idea if it’s working or why it’s not. True ownership means having the visibility to answer those questions confidently.

Your 3-Step Challenge to Get Started

Taking ownership doesn’t happen overnight. It starts with small, intentional steps. Here is my three-step challenge to help you begin this journey.

3-Step Challenge

Get Curious: Find your project’s CI/CD pipeline configuration file. You don’t have to understand everything, just read it. See what it’s doing.
Learn the Fundamentals: Pick one area—like Docker or CI/CD—and learn the basics. A fantastic free resource for this is https://roadmap.sh/devops.
Raise Your Hand: The next time a small, deployment-related task comes up, volunteer. It could be as simple as updating a dependency in a Dockerfile or adding a new test step to the CI pipeline.

The goal is to stop being a developer who just writes code. Become the engineer who confidently delivers value. That journey begins when you decide to own your deployment pipeline.

Resources

Slides

./J

Adopt AI-Assisted Code Development. Now!

Mon, 16 Dec 2024 13:50:05 -0600

The productivity improvements an AI-assisted code development tool can bring to your workflow are significant.

If you are not convinced, allow me to give you one recent experience of mine.

Me, like many of you, have a bunch of personal projects that I work on in my spare time. I’m currently building something around AWS, using the AWS JS SDK and Next.js. In one of the pages, I want to list all the EC2 instances in my account. The table should also list the tags for each instance. But the way AWS stores tags is not very convenient to work with when you want to display them in a table.

The Tags[] property, which is of type EC2.TagList has the following definition:

type Tags = {
  Key: string;
  Value: string;
}[];

This definition gives you values in the following format:

[
  { Key: 'Name', Value: 'My EC2 Instance' },
  { Key: 'Environment', Value: 'Production' },
  { Key: 'Owner', Value: 'John Doe' },
]

I will be rendering this in a table, so I would rather have the data in the following format, which is easier to work with.

{
  Name: 'My EC2 Instance',
  Environment: 'Production',
  Owner: 'John Doe',
}

The definition I want for this, would be,

1
2
3

type Tags = {
  [key: string]: string;
};

I want to redefine the Tags property to the format I want, while keeping all the other properties of AWS.EC2. Or in other words, I want to extend the AWS.EC2 type definition but change the Tags property to the format I want. This is the code I wrote and the error I got,

interface ExtendedEC2Instance extends AWS.EC2.Instance {
	Tags: { [key: string]: string };
	Region: string;
}
// Interface 'ExtendedEC2Instance' incorrectly extends interface 'Instance'.
//   Types of property 'Tags' are incompatible.
//     Type '{ [key: string]: string; }' is missing the following properties from type 'Tag[]'

This is where the AI-assisted code development comes in. Instead of spending time searching and understanding the error message, and then figuring out how to fix it, my IDE can do it for me.

I use Cursor. It understands the code and the context of the code. I asked it to fix the error for me and it gave me the following code,

interface ExtendedEC2Instance extends Omit<AWS.EC2.Instance, 'Tags'> {
	Tags: { [key: string]: string };
	Region: string;
}

TIL, about Omit in TypeScript.

Explanation:

It’s the ability of the assistant to explain the code that amazes me every time. If I had to figure out the solution myself, it would have taken quite some time. But with that suggestion, I was able to understand the problem, learn something new, and get back to what I was doing.

Over time, these incremental improvements adds up. You can finish whole modules in a matter of minutes. $20 a month of this kind of productivity is a small price to pay for the time you save.

Cursor or any other AI-assisted code development tool is analyzing your code in real-time and that's how it understands your code and the context of the code.

If you are working on a project that is not open source or sensitive in nature, you might want to check with your organization before adopting any kind of tool.

./J

The Sunday Test

Sun, 22 Sep 2024 20:23:44 -0500

Recently I read an article about how Stripe built one of the best engineering teams. I have used their products and I have to admit that it’s just well built. Clean, precise and easy to use. Love their documentation too. When i came across this article I wanted to know how they built their team.

What stood out for me was the section about “The Sunday Test”.

The Sunday Test

While other sections about treating recruiting as marketing, valuing rejection experiences, and leveraging existing engineers for talent sourcing were valuable, The Sunday Test was different.

If this person were alone in the office on a Sunday, would that make you more likely to come in and want to work with them? If the answer is not a clear yes, then don’t make the hire.

This is brilliant!

Reflect on those times you sacrificed weekends or worked late nights to meet deadlines. What memories do they evoke? Are they stories you’d share fondly, or tales of exhaustion? The best work stories revolve around the joy of creation, where time becomes irrelevant. The memories evokes endorphins and that incredible feeling of accomplishment.

The worst ones? Tales of misery endured for the sake of a paycheck.

The Sunday Test just summarized all of that. I’m adding that into my hiring-rulebook!

This seems like the ideal time to share my assessment process. Post technical evaluation, I categorize candidates into specific buckets.

My hiring rubric

This is not something that I came up with. I borrowed this from an acquaintence. You can find other variations of this on the internet. But this is what I have adapted for my hiring process.

Ideally, any candidate I hire fits into at least 2 of these 3 categories:

Hacker

Is the person a hacker?

Is this person a knowledge powerhouse? Do they possess near-encyclopedic understanding of the topic at hand, be it a language, framework, or technology? Are they so skilled that their experience surpasses most?

That is the Hacker!

Hustler

Is the person a hustler?

Is this person driven? Do they overcome knowledge gaps with determination? Will they utilize every resource available to achieve their goals? They refuse to be hindered by limitations.

That is the Huslter!

Artist

Is the person an artist?

Does this person infuse creativity into their work? Do they produce elegant designs, self-documenting code, and clear solutions? They take pride in their craft and readily share it.

That is the Artist!

What you need in a candidate is a comnbination of any two of the above 3 skills.

Hacker + Hustler
Hustler + Artist
Artist + Hacker

Someone with all 3 skills, awesome!

However, someone fulfilling only one skill is undesirable. Why?

Now I layer The Sunday Test on top. If they pass the hacker-artist-hustler rating, then do they pass The Sunday Test?

./J

To Care!

Thu, 13 Jul 2023 23:10:18 -0500

Take a look at the photo 🌌. It almost looks like a photo taken by an amateur stargazer. Grainy streaks of sunlight.

But this photo was taken in 1990 and was not taken from Earth. A machine took it, the right technical term being space probe. It was called Voyager 1, and it was launched in 1977. Voyager 1 traveled 13 years and 6 billion kilometers into deep space, very, very far from home, to take that photo using instruments that were cutting-edge in 1977.

Let’s look at the photo again. Notice that streak of light towards the right side of the photo. Zoom into the photo, and you can see a very bright pixel somewhere around the middle. Looks blueish and could easily be dismissed as an overexposed pixel.

That’s Earth! 🌏

Carl Sagan, in his book Pale Blue Dot comments on what he sees as the greater significance of the photograph, writing

From this distant vantage point, the Earth might not seem of any particular interest. But for us, it’s different. Consider again that dot. That’s here. That’s home. That’s us. On it everyone you love, everyone you know, everyone you ever heard of, every human being who ever was, lived out their lives. The aggregate of our joy and suffering, thousands of confident religions, ideologies, and economic doctrines, every hunter and forager, every hero and coward, every creator and destroyer of civilization, every king and peasant, every young couple in love, every mother and father, hopeful child, inventor and explorer, every teacher of morals, every corrupt politician, every “superstar,” every “supreme leader,” every saint and sinner in the history of our species lived there – on a mote of dust suspended in a sunbeam.

Why am I talking about this?

There was a phase that I went through where I questioned everything. I came across this photo and quote by Carl Sagan, and it greatly impacted me.

It started off with “Nothing we do matters“. A phase of fuck it attitude towards life and everything. The mote of dust we are on can be wiped off by a rock or radiation. Then why even care? Thankfully, that phase didn’t last. Realised that I do love and care about some things in my life. Things I don’t care about might be something others care about. Because I believe in something, I cannot ask someone to think and act like me. (Except when it comes to tech and designs). Let them be. Everybody has “stuff” they care about and crap to deal with. You might not even be aware of that. The best I can be is not to become another cause of worry they have to deal with.

These days, I try to leave everything in a better state than I found it – people, relationships, places, pieces of code. It keeps me happy and satisfied mentally. More often than not, things do not pan out that way. As human beings, we are flawed. Mistakes happen, and I try to fix them as much as possible. But most of the time, I’m a fucking goldfish. (Thanks to Ted Lasso, there’s a word for it now!)

💥 Boom!, light bulb 💡 moment!

So thanks to Voyager 1 and that photo, at any given time, I don’t, and I do give a sh-t about things. Like the famous cat in the box! 🐈📦☠️

The difference between the cat and me? I’m pretty sure I’m alive. Or am I?

./J

The Underappreciated Skill of Comprehension

Wed, 12 Jul 2023 23:09:43 -0500

Comprehension is the understanding and interpretation of what is read.

Documents at work are rarely 140 characters or 140 words or even a single-page document. Whoever wrote that document has put their thoughts into words. It would have been peer-reviewed. Revisions made and approved for general consumption. It might not be the best-written technical document or the best way to string words together, but it nevertheless captures an idea.

You might be a super-star developer or a kick-ass architect, but it’s a big red flag for me if you don’t know how to read and understand a document/mail/incident report without someone explaining it. It is a skill that lets me measure your ability to work independently.

I’ve seen this happen time and time again with new graduates. They’re brilliant at their technical skills but struggle to comprehend written information. They ask questions already answered in the document and make mistakes because they can’t understand the instructions.

This is a concern because it slows the team and leads to errors. It’s also frustrating for the people who have to explain things repeatedly.

Check this question,

Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.

It’s the second question at Project Euler.

This is one of my interview questions. Most people I interview generate four million numbers or the first few numbers in a Fibonacci sequence. People deserve second chances. So I ask them to reread the question carefully. Still, the majority can’t understand what is expected as a result.

How to improve?

So what can you do to improve your comprehension skills? Here are a few tips:

Read regularly. The more you read, the better you’ll understand written information.
Pay attention to the author’s style. How does the author structure their sentences? What kind of vocabulary do they use? The more you pay attention to the author’s style, the easier it will be to follow their train of thought.
Ask questions. If you don’t understand something, don’t be afraid to ask for clarification. It’s better to ask a question than to make a mistake.

So please, pick up a book, newspaper, online article, or anything longer than a page, and make it a habit to read and do it daily.

./J