Arsh Goyal Said Coding Is Now a Commodity. A Once-Failed Engineer Writes Out Everything Behind 'Engineering Thinking'

Yesterday I was writing about security.

45% of vibe-coded code has security vulnerabilities. Cisco responded by launching Project CodeGuard. I finished that piece with a quiet sense of relief — “we’ve entered an era where big companies are lending a hand.”

The next morning, a different question surfaced.

What comes after fixing security? Beyond “can write code” and “can secure it,” isn’t the next question about what to build? Right at that moment, I read a statement by Arsh Goyal — and it’s been in my head ever since.

---

Coding Has Become a Commodity

Arsh Goyal, an India-based engineer and content creator, stated this flatly at the developer conference DevSparks Pune:

“Coding is getting commoditized. Engineering is a different dimension.”

“Commodity” means something that has lost its scarcity — like iron or wheat, something anyone can obtain. Coding becoming a commodity means the premise that “people who can write code are rare” is collapsing.

When I first read this, I’ll be honest — it unsettled me.

Through vibe coding, I’d finally gotten to a place where I could write code. Multiple times I’d felt like I’d channeled some expert engineer. If that capability is becoming commodity — meaning something anyone can have — then what was my “I finally got this” worth?

That question changed direction in about 30 minutes.

What’s being commoditized is the act of writing code. With AI now widespread, code generation is being rapidly automated. GitHub Copilot’s autocomplete is sharper, Claude Code outputs complex implementations in minutes, Cursor proposes refactors. The very fact that vibe coders are proliferating proves the commoditization is underway.

So what rises in value once “coding” itself is a commodity? What specifically does Goyal mean by the “different dimension” of engineering?

To address that question, let me start with the external data.

---

What Deloitte’s 2026 Report Is Seeing

The Deloitte 2026 Global Software Industry Outlook analyzes structural shifts in the software industry each year.

The same shift is visible across the industry.

As code-generation AI has spread, the skills demanded from engineers are shifting from “implementation” to “judgment.” There is growing weight on “what to build, and why” over “what to write and how” — that is the broad direction Deloitte’s analysis points to.

The same pattern shows up elsewhere.

GitHub’s annual Octoverse survey shows a growing trend of responses indicating that time spent on design, review, and testing has increased alongside the spread of AI coding tools. Cursor has also noted in official blog posts that “the difference in outcomes comes from what instructions you give, not autocomplete precision.”

The pattern is consistent.

“Writing” gets automated. “Judging” remains. The boundary between coding and engineering is now being made visible at high speed.

A clarification on what Deloitte means by “shifting to higher-order skills”: the ability to evaluate multiple technical options and choose the best one; the ability to prioritize while tolerating ambiguous requirements; the ability to bridge business goals and system constraints. These are all areas where AI struggles. AI is good at optimizing code within given constraints — but it struggles with the question of which constraints to set in the first place.

Cisco’s Project CodeGuard, which I wrote about yesterday, sits on the same map. Security problems can’t be solved by “can write code” alone. They require judgment about what to protect and which risks to prioritize. Coding gets commoditized; the judgment layer of engineering doesn’t automate — this structure keeps being made visible through each company’s moves.

---

The Difference Between Coding and Engineering Thinking

They sound similar, but they are quite different in practice.

Coding is the act of translating given requirements into code. Input in, output out. It’s what AI does best — and it’s already being automated at high accuracy.

Engineering thinking is the capacity to ask what should be built in the first place. It means defining requirements themselves, having principled design judgment, and being able to verify whether what you built actually creates value.

A concrete example.

“I want to build a bot that auto-replies to Slack messages” — this is an input for coding. Hand it to AI and something that works comes out. Done in 30 minutes.

“Will adding this bot actually reduce the team’s response cost? Or might it just increase noise? Wouldn’t it be faster to reduce message volume in this Slack channel first?” — this is an engineering thinking question. Only someone with context can ask it.

When I build work tools myself, the second type is where I spend the most time. I think first about “what changes for whom, how, when this tool goes in.” After that answer emerges, I ask AI for the code. Flip that order, and you get things that work but nobody uses. I’ve built a few of those.

From years in CS hearing “I don’t understand why it works this way” thousands of times, I can say: the quality of the question determines the value of the tool more than the quality of the code.

One story about when I felt this most sharply.

I once tried to automate report generation for my team — a script that pulls weekly KPIs from spreadsheets and posts to Slack. Built it with AI in two hours. It worked perfectly. The following week, nobody was opening the Slack notification.

The problem definition was wrong. The problem wasn’t “get KPIs into Slack.” It was “build a system that makes everyone treat weekly KPI review as their own concern.” The assumption that automation would make people read it was wrong. I hadn’t asked, before writing the code, “when this notification arrives, what will team members actually do?”

---

The 3 Axes of Engineering Thinking

I don’t want to end with abstraction. Let me break down what I call “engineering thinking” into 3 parts drawn from lived experience.

Axis 1: Define the Problem Precisely

Before writing code, can you state “what is the problem” in one line? That’s the first axis.

A common input is “I want a dashboard.” But the real problem might be “I spend 30 minutes every morning manually checking multiple sheets.” Change the problem definition, and the solution changes too. Sometimes a script that auto-posts a summary to Slack each morning is faster than a dashboard.

I’ve built the habit of writing “the problem I want to solve in one line” before writing any AI prompt. That one line creates a standard for evaluating AI-generated code. Instead of “it works,” I can ask “did it solve the original problem?”

This problem statement also improves prompt quality. “I want to eliminate the 30-minute manual aggregation I do each morning — currently checking 3 spreadsheets by eye” produces more precise code than “build me a dashboard.” The act of defining the problem itself raises AI collaboration efficiency.

A template I use: “[Who] spends [how long] doing [what]. I want to get it to [target state].” For example: “Our sales team spends 2 hours every week building reports. I want to get it under 15 minutes.” Put that sentence at the top of your prompt and the AI’s output direction narrows considerably.

Axis 2: Judge the Tradeoffs

Design always involves tradeoffs. Speed vs. accuracy, simplicity vs. extensibility, current cost vs. future flexibility — take one, give up another.

AI can walk you through both sides of any tradeoff carefully. “Explain the tradeoff between A and B” gets a precise answer. But the judgment of which to choose belongs to the human with on-the-ground context.

“For this operation, is speed or accuracy more important?” — that question belongs to someone who knows the workplace.

I once spent 3 hours with vibe coding to build a tool, then wanted to redo the design later. The problem was deferring the design judgment. Because AI moves fast, you need to consciously bring design decisions forward. The cost of the rebuild was recovered in 30 minutes of upfront thinking.

When a fork appears, I don’t immediately pick one. I ask AI to “list the tradeoffs between A and B,” then make the judgment myself. Just making that a two-step habit changed my design awareness.

Axis 3: Evaluate What You Built

The moment code runs is exhilarating. “It actually works!” is a feeling that never gets old.

But “working” and “valuable” are different things.

“The Slack bot can now reply” is the working state. “Response cost dropped by 3 hours a week” is the valuable state. The ability to measure that difference is the third axis.

My practice: use what I built again 2 weeks later. With the excitement of release cooled, I check 3 things: “Am I still using it?” “What’s getting in the way?” “Was the original problem solved?”

Taking this cycle seriously reveals surprising things. Something I thought was a “god-tier tool,” I find I haven’t opened in 2 weeks. Digging into why, it’s always either “the problem definition was wrong” or “the design judgment was off.” Running the evaluation cycle sharpens the next problem definition.

These 3 axes aren’t independent — they cycle. The more precisely you define the problem, the sharper your design judgment. The results of your value evaluation feed back into the next problem definition. Consciously spinning that cycle is what turns vibe coding from “producing things that work” into “producing things that create value.”

---

What Being a CS-Background Dropout Engineer Taught Me

As I said at the start, I once gave up on writing code.

The gap between myself and the engineers I met on a large-scale project was almost refreshingly clear. The beauty of their architecture, the intuition behind performance tuning, the polish of their code — there was genuinely a place I couldn’t reach. So I shifted into CS. CMS implementation support for content marketing, media growth, management — three years away from code.

What I felt I couldn’t reach back then was the “coding” part.

Looking back now, I was building a different capability in CS.

Days of constantly asking “who is this feature for?” Hours staring at numbers asking “why are users dropping off here?” Three years of daily questions like “can readers actually act on this content?” Thousands of moments hearing “I don’t understand why this works this way” — these were all training in engineering thinking. Without code.

Now that vibe coding has gotten me to a place where I can write code, that training is directly applicable.

When the capacity to ask “what to build,” “who to build it for,” and “whether it worked” combines with AI code generation — that’s when it clicked. The capabilities Arsh Goyal means when he says “engineering is a different dimension” — I’d been accumulating them on a different path during those three years away from code.

The choice to fail and move into CS wasn’t a detour.

It was time building the core of engineering thinking — that’s how I see it now. This interpretation might be self-consolation. But every time I build a tool through vibe coding, the habits of questioning from my CS years support my design judgment. I’m not just “able to write code” — I’m building in a state where I know “what should be built.” That difference shows up in the actual output.

If coding is what’s being commoditized, then time spent outside of coding is an asset. The era has come where past failure becomes a weapon — at least in my case, that’s how it feels.

One more point.

I sometimes wonder what the expert engineers I met on that large-scale project are doing now. Their coding skills were genuinely the real thing. But as AI writes code, there must be more and more situations where technical skill alone isn’t enough. Engineers with coding ability but no engineering thinking face growing AI replacement pressure. Conversely, engineers with engineering thinking can use AI as a tool and increase their value. The commoditization wave doesn’t swallow everyone equally.

---

3 Practices for Vibe Coders Starting Now

Engineering thinking is trainable. It’s not difficult theory — it’s a habit question.

Practice 1: Write One Problem Statement Before Every Prompt

Before asking AI for code, write just one line — on paper or in a note. “This is the problem I want to solve.”

Not “build a dashboard” but “eliminate the 30-minute manual aggregation I do every morning.” Writing the problem creates a standard for evaluating the generated code. You can ask “was the problem solved?” instead of “does it work?”

Since starting this habit, my prompt quality has improved. The more specific the problem statement, the more precise the code. The act of framing the question doubles as prompt engineering.

Practice 2: Generate 2 Design Options Before Choosing

When a technical fork appears, don’t immediately pick one. Ask AI to “list the tradeoffs between A and B,” then make the judgment yourself.

When you can articulate “why I chose this,” you can revisit the design later. If you don’t know “why I decided that,” you repeat the same mistake when rebuilding. Adding this two-step process changes your design awareness.

Practice 3: Use It Again 2 Weeks Later

Not the day after launch — 2 weeks later. Check just 3 things: “Am I still using it?” “What’s getting in the way?” “Was the problem solved?”

Running this cycle once sharpens the next problem definition. The difference between “a thing that works” and “a thing that gets used” becomes embodied, not just theoretical.

None of these 3 practices are difficult. Not difficult, but you won’t do them unless you’re conscious of them — because the most natural flow is “hand it to AI, code came out, done.” Training engineering thinking means inserting conscious steps before and after that natural flow.

---

Closing

Arsh Goyal’s words point to a future that is, in one sense, simple.

Being able to write code becomes table stakes. With AI now widespread, the era of “people who can write code are rare” is ending.

What holds value beyond that is engineering thinking: the ability to define problems, judge design, and evaluate value. These 3 axes won’t be automated by AI.

Through the three years of failing at coding and moving to CS, I was walking an alternate path toward engineering thinking without realizing it. Now that vibe coding has gotten me to “able to write code,” that accumulation has finally found a place to work.

“Can write code” has become the entry fee.

The next question is: what to build, for whom, and how to design it. The people who hold that question and keep asking it are the ones who can walk beyond the commodity — that’s what I believe.

Returning from code wasn’t over when I got “able to write code” back. “Able to write code while holding engineering thinking” was the real goal, I understand now. Vibe coding is the doorway. Beyond the doorway, there’s still a long road. I want to walk that road with everyone who read this article.

---

References

• Arsh Goyal (India-based engineer and content creator) — statements at DevSparks Pune 2026 (from multiple media reports)
• Deloitte 2026 Global Software Industry Outlook
• If You’re Lost on How to Use Claude Code (Nagi)
• The Era Where You Don’t Need to Code Has Arrived with AI (Nagi)