Infosys boss says vibe coding is no threat because there’s more to writing software than writing software

Infosys chairman Nandan M. Nilekani has predicted AI – even AI that does the kind of coding work his company does for many clients – will be good for services companies. Nilekani made his prediction in a speech delivered at the Indian services giant’s annual general meeting on Tuesday. “The industry is going through a major …

[Pete 2]

Coders have the smallest parts

> there’s more to writing software than writing software

Not only is actually writing software a fraction of the entire production process, but it is arguably one of the easiest (with only marketing being a cushier gig). The really hard bits - where most mistakes are made - are in the design including specification, and testing. Design issues rarely show up until it's too late and testing is such a time-consuming chore that it is almost never done properly. Plus, being near the end of the project, it is the function that gets its timescales squeezed to make up for poor project management at every earlier stage.

[Anonymous Coward]

Re: Coders have the smallest parts

Marketing is a cushy gig, but think of the number of software solutions that have been built that have never seen the light of day because the person that built it didn't know how to sell it.

Spec writing for sure is one of the harder steps, it's still highly relevant with AI coding, quite possibly more important than ever.

For the over excited JS folks...he's not referring to that kind of design. You're still ten a penny and largely worthless, you guys were putting out slop long before AI...the nail in the coffin for you guys was frameworks not AI.

I don't think testing is skipped/glossed over purely because it is time consuming. A project usually has a fixed time budget and most of that time budget is taken up by the guys above and their Figma wireframes meetings..."ok we've noted the changes, we'll update the Figma and meet again this time next week"...nothing burns time like a frontend skin maker.

*3 months later...*

Ok we've finally settled upon the final design, the frontend guys will have that ready in 2 months, launch is in 3 months...LETS GOOOOOOO!!!

[Rogerborg 2.0]

Re: Coders have the smallest parts

And "vibe" coding is nothing of the sort, in the sense of implying some sort of feels-based process. You only get what you actually design, via markdown, and your specification *actually* documents what the Clanker produces, rather than being a suggestion about what some meatsack *might* have coded.

[Acrimonius]

Re: Coders have the smallest parts

Not just poor managment blowing all the time but also coders iterating ad infintum and taking their merry time. Coders say we do not need a spec (it is never of much use or even feasible) or a design (always not the way to do it when you start to do it) and it will be ready when it is ready

[powershift]

Re: Coders have the smallest parts

Yeah, design is a biggie but the most mistakes are made in the requirements gathering process of the SDLC.

[munnoch]

Infosys -- an unlikely saviour for the craft of writing software...

[coredump]

Seems like Infosys are simply saying whatever is needed to continue flogging indentured consultants to cheap and/or desperate corporations.

[Anonymous Coward]

I wonder if an Infosys ‘70 hour work week’ Agentic Agent will cost beellions of tokens at AI Partner Anthropic?

[werdsmith]

This I’ve been trying to say for months. AI is very effective as a support to a programmer or for other work.

When used this way the human maintains full oversight and big Frontier models are less necessary.

Something analogous to having a bike available as opposed to walking or running. The bike is a useful boost but it can’t go everywhere.

[Random as if !]

The driverless car can, but it cannot pick up your shopping , or ensure it has all the kids.

Its an internet enabled washing machibe.

[Confucious2]

A lot of humans fail at both as well…

[Richtea]

A lot of PMs fail at both.

[l mdesht]

> Something analogous to having a bike available as opposed to walking or running.

A fine analogy, other than bikes don't consume vast quantities of energy and water to use, and they don't randomly give you a completely made-up answer.

[EricM]

He probably has a point.

If I look at what/how actually has been vibe coded over the past 18-24 months, I cannot help but be reminded to the late 1980s. We are back to the era of the "Whiz Coder Kid", who just coded along - without full understanding, without plan, without architecture, with under-defined specs, but with a massively inflated ego. Double, triple re-implementations of the same functionality instead of re-use. 3 similar frameworks used in the same project. Even redundant databases being thrown in sometimes.

Even if everything kind of "works" on initial deployment, the shit hits the fan on changes and maintenance.

It took the IT industry the better part of a decade to finally bring a structured approach to spec gathering, developing an architecture and (finally) coding, testing and deploying software, after the "Home-Computer" crowd stormed IT departments.

Today, Devs+AI behave much like the Whiz Coder Kids of the 80s, vibe coding their way through existing code bases, re-implementing, circumventing deliberate architecture choices and causing tech debt. They exhibit the same ego problem and they are having the same effects on software quality, just at a much larger scale, thanks to AI.

So, yeah, there might be huge opportunities ahead for Infosys to fix all this vibe-coded mess.

[elsergiovolador]

Re: He probably has a point.

"without full understanding, without plan, without architecture, with under-defined specs, but with a massively inflated ego. Double, triple re-implementations of the same functionality instead of re-use. 3 similar frameworks used in the same project. Even redundant databases being thrown in sometimes."

Very much any enterprise project with multiple consultancies involved.

[Anonymous Coward]

Re: He probably has a point.

Yeah since AI, people are throwing the term "understanding" around ironically missing the fact that pretty much any enterprise development project has a severe lack of understanding by its very nature due to the bikeshedding, crap spec, lack of decent comms and massive over-egging of the middle management allocation that ends up on the projects.

AI doesn't remove understanding, it was never there, it just removes the managers...and therein is the reason you have a lot of combative anti-AI folks.

AI does not remove the developers, it removes the managers, project managers, project planners, department heads, internal experts etc etc...you still need the dev to run the AI, generate stuff with it and then audit the result...but you don't need the 8 extra wankers overseeing it all.

[Rogerborg 2.0]

Re: He probably has a point.

Depends on your definition of "developer". The crucial point is specifying exactly what you want in markdown, and then letting the Clankers loose on it.

When product managers figure this out, it makes code monkeys obsolete. Ultimately, it means that even the lying weasels in sales can actually make good on their wild promises, if they can figure out how to turn it into .md files.

[Anonymous Coward]

Re: He probably has a point.

True. The term "developer" is a pretty loose term these days.

Put simply, I would consider any form of programming that is lower level than UI to be "development". Modern UI and frontend is to programming and development what building an IKEA wardrobe is to carpentry...there are exceptions of course, but for the most part, that's how it is.

"When product managers figure this out, it makes code monkeys obsolete".

I somewhat agree with this, but only to a certain extent.

I think with AI, I can see a world where the frontend prompting goes to the project manager whilst the backend devs and engineers go nowhere. You don't really need a technically proficient person for frontend anymore, even before AI it wasn't a massively technical job thanks the rise of UI frameworks etc...as long as all the heavy lifting etc is done by the backend guys and they've nicely documented it, it is entirely possible to point ChatGPT at it and have it produce a nice skin for it.

I think for quite sometime, from the customer perspective, there has been somewhat of a biased view in terms of how different kinds of developers are perceived. For a long time UI/UX has been viewed as disproportionately important...because they produce the bit the customer can see, interact with and have opinions on...they're in the room with the client...backend not so much, that's abstract to most folks outside of tech.

The main advantage AI brings to the table for UI/UX is this customer can input their thoughts, opinions etc and see the changes in real time...there is no "we'll go away and do that, and we'll have a meeting same time next week to discuss"...there is no abstract wireframing...there is only "lets see what that button looks like in green, also align all the text on the page to the left, lets see what that looks like". AI is very good at this...I have to admit, as a backend guy myself, I've been using AI a lot for frontend, I used to rely on various different sources of UI for prototyping...bootstrap, tailwind, themeforest etc etc...and I'd have to spend considerable time bending these things to my will to work with the backend just to have something the customer can interact with to get a feel for it...these days, I don't have to spend anywhere near as much time doing that...I also don't have to have nearly as much cruft involved just to throw a quick UI on something...I'm mostly getting AI to build prototype UI in pure HTML5/CSS...no React, no Tailwind, no Bootstrap...nothing...just pure HTML and CSS...this has a lot of benefits, it's way easier to document, it's way easier to polish into a final product and it allows me to sit with the client and an AI model for a couple of hours to dial things in...all of this shaves off huge amounts of time that I can pour back into refining the backend...where I don't really use AI outside of conceptualising and planning...there isn't as much of a time gain there having the AI write the code because I still have to audit it and it's very common for the AI to end up going in circles and disappearing up it's own arse.

There are a few reasons I stick to pure HTML and CSS on the front end as well...first and foremost, you get a lighter product, secondly it massively saves on token usage because your LLM isn't having to constantly send npm build output to itself for debugging and finally, you end up with way less code to audit and it's much easier to read when you do audit it.

I would absolutely say that UI/UX as a career is largely done...or at least, as we know it, I think the canary in the coalmine there is watching what happens to design agencies, I'm already seeing quite a few disappear or merge...timescales are going to shrink for that area as are the budgets...the beneficiary of all that will be the backend engineers, because the overall project budget will remain the same, but more of it will be spent on the technical side rather than that fluffy side...which I think will eventually lead to much better, less buggy projects simply because you won't have the front end guys wasting 4 months of a 6 month project on back and forth...a 6 month project might turn into a 4 month project, but the backend guys will likely end up with a month of extra time because the frontend stuff will drop down to a month or less, maybe even a week...

I also think the workflow for larger projects will turn on it's head. Instead of engineers spending time building a prototype, then the agency coming in and spending 4 months on front end, then the engineers getting a month at the end to finalise the product, I think we'll see prototyping at the same stage, then finalising the backend, then the agencies will come in for a few weeks at the end...if they're even needed at all. They may only exist in a marketing capacity and have nothing to do with the product itself in the future...who knows?

[Anonymous Coward]

Re: He probably has a point.

I think it's great that we're back to that sort of vibe...we might finally see some innovation again. Sure a lot of shit will catch fire and explode along the way...but tech has been boring and stale for nearly 20 years now.

If I have to go another year getting stuck in meetings dominated by some bikeshedding JS framework using Figma wanking skids that call themselves developers, it'll be a year too long.

We all think it, I'm just saying it out loud...

We're finally getting back to things being rapid, experimental and interesting again...the strong bond that kept frontend guys latched on to making clones of the Apple website in ReactJS is starting to soften.

Is shit going to break? Absolutely...will we learn from it? Hell yeah! In short order we're going to be able to crank out the fluff at hellish speed and we'll get more budget for the stuff AI can't do (yet) which is work on the architecture and infrastructure...we might finally start building projects that aren't bloated to fuck with npm packages again.

The only reason JS frameworks are heavily used is because of how long it takes to manually code frontend, since AI is orders of magnitude faster than a human, you no longer need the frameworks...every frontend I've produced with AI has been pure CSS and HTML. They're easy to audit and light as a feather...and crucially, no supply chain attacks.

I still hand code backend tech, with the odd bit of assistance from AI if I need to document, solve complex problems I don't fully understand or perform intense donkey work like processing masses of data...I'm quickly reaching a point where I might be able to eliminate third party packages and libraries entirely...or at the very least, cut it back significantly, those that I can't avoid I can use AI to help check for malicious code, fork it and maintain a separate repository with that library in that will never be subject to supply chain attacks...because I will only ever pull in that version of the library.

Out side of professional bread and butter land, I have been able to bring back tons of my projects that have been shelved for years because I don't have to face the trudge of fucking around with a frontend framework to finish them off. For me, solving problems and building them is where the fun is, designing frontend is not fun...it's boring and tiresome and I don't want npm packages in my products. I want to design frontend the way I used to, 20-30 years ago...throw together the UI in Photoshop, GIMP, Inkscape or something, then turn it into pure HTML/CSS...AI helps with this massively...if you're a frontend guy, this is where you need to go...stop pretending you're a developer, you never were, and go back to Photoshop where you belong...we can all be friends again...think about it, that Mac you bought...you'll finally be able to use it for what it was designed for!

[dgc03052]

Re: He probably has a point.

"eliminate third party packages and libraries entirely"

Not sure this is such a good thing, having watched a project completely botch dealing with changing database schema's over time.

- Just checkin edits to "the" DB creation script

- create migration scripts, but also change the creation script, so anyone who already had a DB got different results

- create migration scripts, but go through multiple rounds of naming conventions, as people keep getting merge failures, and still not being able to handle differing branches

- create migration scripts that couldn't handle existing data

All instead of using existing libraries that had already dealt with all those typical issues

[Anonymous Coward]

Re: He probably has a point.

True, there are situations where libraries make sense...at the low level.

It depends on what the library is for and where it is used. If it's a wrapper for a wrapper...i.e. just abstraction. You don't need it. If the library is a driver of some kind, you probably do because if you don't use the library you're probably re-inventing the wheel for no reason.

For example...using a SQL library that is designed purely to connect directly to your backend database and expose that functionality in your app. Perfectly fine, you're not going to want to write a brand new raw socket level library if one already exists. That is one library.

Using a database library that wraps this functionality into a layer of abstraction just to make it easier to use, now you're getting into the realms of questioning it. You're now two libraries deep and one layer of abstraction away from the functionality you actually needed.

Using a library that incorporates 3 or 4 of these libraries, that each have their own lower level library to enable the same syntax to be used across multiple database technologies (you know, in case you migrate one day)...well now you're in the realm of have two layers of abstraction at the top level to connect to one kind of database...but you also have the baggage of 3 additional low level libraries you aren't actually using, with a layer of abstraction on top of each before you reach the top layer of abstraction...you now have 4 low level libraries and 5 abstraction libraries...each probably coming with their own dependency libraries, just to connect to a SQL database. That is not only needlessly complicated, it is also a massive attack surface and for the sake of "just in case" you've probably added dozens of dependencies to your project...that's insane.

You could go even further than this and say "well I don't do that, I just use ReactJS"...well ReactJS probably includes all these wrappers around wrappers for wrappers in order to surface functionality in itself...ReactJS relies on somewhere between 200-250 libraries (or dependencies/packages if that's what you want to call them)...most of those are dependencies for the dependencies...something as simple as a SQL query could be going through 5-10 packages for all you know...each one of them burning CPU cycles and using RAM...even worse, when you're several layers of abstraction away from the business end of something happening, you generally have less control...you might lose huge amounts of performance because there are behaviours your can't tune...like database session pinning, idle sessions, idle connections, new connections spawning with every query etc etc...this doesn't include all the dependencies that nodejs itself relies on or npm.

[Rogerborg 2.0]

Re: He probably has a point.

If you're talking about what WAS produced by Clankers 18-24 months ago, that's already ancient history. What matters is Clanker capability today, and tomorrow, particularly with new projects.

Even the most minimally competent slop-coder will produce spec -> tech stack -> implementation plan markdowns, all of which will be points of truth about what's in the generated code.

This already puts us ahead of the traditional process of a team of code monkeys slapping together whatever they individually need to do each task - with all the duplication, redundancy and duplication that typically occurs - and then trying to discover, document, and refactor that later.

Fixing a "vibe coded mess" is substantially easier, because you start with better specifying what you want in the markdown, and can rebuild the whole executable from scratch (tokens allowing) with higher confidence than trusting meatsacks to do what you told them.

[Anonymous Coward]

Re: He probably has a point.

Careful man, you're using terms in there used by frontend people that think they're devs...you might make some people angry.

Remember, 75% of their billable time is meetings and AI is taking that away. The other 25% is browsing ThemeForest, stock photo libraries and using Figma. They might run out of money to pay their indian devs with.

To be fair, fixing "vibe coded mess" is a mixed bag. It depends on who prompted the AI and how they went about it. I think an absolute noob that has never coded in their life is likely to produce absolutely unmaintainable code...it's proof of concept at best.

That said, a highly skilled developer is entirely capable of vibe coding something to production level...no question about it.

I think once we de-stigmatise vibe coding and all the React devs go back to McDonalds we're going to see a lot of interesting stuff come out of developer/AI partnerships...especially as project friction is removed. The key thing is AI lets you test ideas and work out feasibility a lot faster...A LOT. You can have a brainfart and have a proof of concept in under an hour. Two hours later, you're onto the next brainfart...in a week you can have tested so many different concepts, that it might lead to something that isn't just a brainfart...you'll discover something that didn't even enter your mind until you started exploring.

This is what is exciting...because we're going to see a lot of interesting new concepts and ideas appear from the developers that remain. Not just another recreation of the Apple website in ReactJS for the 8 millionth time that day...another 5,000 shadcn dashboards with "apis for developers"...we might start seeing actual products for people. The death of "unified API that brings in the power of 10 APIs into one API, save money with our three simple payment tiers bleugh" for the 9,000th time...you know, the endless production line of SaaS solutions looking for problems.

[[e-mail]]

Well duh!

Anyone who has worked as a software development consultant knows that the key to a vibrant industry is creating bugs for the next company to fix, while you go on to fix bugs at their client. Vibe coding does this automatically and you don't even have to move to a new client!

[fg_swe]

Darwin Will Do It

Applied Computer Science is an enourmous number of fields from beancounting to games to ABS brakes.

We know how to do all of it properly - the V Model. But thats too expensive for many settings. So all kind of insane corner-cutting will be done.

AI definitely can help in fast coding of simple algorithms, which already exist somewhere. It can be done responsibly.

But guess what ? Irresponsible MBAs and similar will abuse it, because they dont know and do not want to know, the limits of AI.

Also see Boeing MCAS: MBAs decided to let it develop in India by rookies. It cost 300 dead passengers+crew plus $25 000 000 000 in follow-on damage. The MBAs wanted to save in the order of $30 000 000. Indian rookies did not know the basics of sensor failure validation and they faked a sensor fault test case.

We will see an MCAS level of AI coding desaster and then more responsible approaches will be taken.

[Anonymous Coward]

Re: Darwin Will Do It

Someone I know works for a well known UK financial institution - they are heavily invested in moving their IT development to India. The horrors they recount of some of the mistakes, some of which are trivial and not expected of a company like this. The company also want to see a cultural shift towards embracing AI

[fg_swe]

Moneymen...

The folks running the London Stock Exchange outsourced trading software development to Sri Lanka. Because they were even cheaper. And as you know, you need the cheapest input in order to get the best profit. A Fiat is always cheaper and therefore better than a Mercedes, you know.

They then experienced several full-day crashes of the trading system.

[Fruit and Nutcase]

Re: Moneymen...

A Fiat is always cheaper and therefore better than a Mercedes, you know.

Yes, I can see that argument being accepted by the management.

[MazeFrame]

Re: Darwin Will Do It

I am waiting for the big license-server in the cloud incuded outage that brings a country so close to collapse their neighbours put on the blue helmets while manning the disaster relief trucks.

With the trash-tier software created in the 2010s leading up to the virus years, what once used to take a few MB of (now costly) RAM is now in the Gigabytes, while also hogging CPU cycles to send more data to the mother ship.

The old joke applies: Coding a bar is easy, then you test ordering 1 beer, 2 beers, 239478 beers. 2+2 beers. Customer walks in, asks for the bathroom and the thing explodes!

[O'Reg Inalsin]

Be the change.

Maybe this will be the incentive that Infosys et al need to move up from the low hanging fruit.

[Luiz Abdala]

Writing code is easy. Writing the algorithm is the hard part.

Once you got what you want done in the smallest detail, you can put it in algorithm form, and then you could deliver that to any language coder and get it done.

I had my run-in with Pascal (and Delphi) and the hardest thing was to make the algorithm do what you wanted.

[Slant Four]

what gets missed by non-programmers

or crap programmers is that (in my experience if you do it right) 40% to 50% of your code is there to validate the rest (the stuff that reads, writes and processes data and executes "stuff")

And to do this (validaiion) you need to think hard about all the validation points needed and obviously it makes sense for common validations to makes these some kind of common function/subroutine.

Simple case in point: data entry of a formatted number (credit card or US SSN) or formatted alpha/numeric (say car rego plate) etc etc.

Obviously validation is not only data that is input but also output from a say called function (I.e. in a mission critical situation never trust the result set) or just simple stuff like checking return status of system called functions.

This is what I see missing with AI generated code in combo with careless programmers or those with no skills who are vibe coding.

Peter

[fg_swe]

More Than Return Codes

There is plenty of good training data out there on github for the AI to learn good code. Return codes will be checked, at least when you complain to the AI.

BUT - checking return codes does by no means assure correctness of code. It's just one facet of many that will make a system reliable and correct.

Someone will have to check the AI output and make adjustments to the AI build pipeline.

Someone will have to check the test cases on all levels of the V model.

This someone will be under lots of pressure, because the project is typically underfunded and understaffed. Or underqualified.

[Pulled Tea]

Translating from corporatese…

“Are you kidding? We're going to make so much money having to clean up and pick up the pieces from the idiots who let the hallucinating chat box do their jobs, we won't have enough people to take it all!!”

[Fruit and Nutcase]

Still work 72 hour weeks?

Are the coders still expected to work 72 hour weeks, as per wish of co-founder?

https://www.theregister.com/security/2025/11/24/70-hour-work-weeks-no-longer-enough-for-infosys-founder/2829624

[Confucious2]

Re: Still work 72 hour weeks?

If people work 72 hour weeks it will make him very rich, after all, it worked for Elon Musk.

[BenMyers]

More to writing software than writing software, for sure

Infosys guy is spot on. Once the software is written, it needs to be tested to make sure it works according to spec and all the coding errors are wrung out. Depending on the complexity of the software and its dependencies on other software, this could take a long time if done well.

[fg_swe]

Re: More to writing software than writing software, for sure

Probably the AI can write the test cases, as mandated by the V model.

But who ensures the quality of the test case code ? Who ensures that e.g. system test cases really cover requirements fully ?

AI will change software engineering, but not make it easier. It will automate lots of routine tasks, but will require senior engineers to spot hallucinations with eagle eyes. Then talk sternly to the AI ;-)

[Anonymous Coward]

Friends don't let friends join Infosys. Absolute shite company. I'd rather be unemployed then work for those shysters again.

[Anonymous Coward]

This is a simple math problem presented in a question.

Is the cost of doing it in AI more than the cost of Infosys employing someone on peanut wages working 70 hours a say?

The answer to that question due to the amount of money thrown at AI as investment that requires returns is going to be no if it's not already no. The initial danger of AI being a buzzword bingo word is also starting to wain.

As much as I dislike Infosys I don't think they have anything to worry about.

[cookiecutter]

just don't!!

if a supplier is vibe coding, why am I paying them?!

same with business consultants using AI to write reports?

why would I PAY a 3rd party probably double or triple what an internal mender of staff would cost if they are going to AI the job? Might as well bring it in house & mainly reduce my risk profile .

these people are a genuine fucking joke

[fg_swe]

Indeed

Why pay the farmer for food, when the tractor pulls the plough ?

Pol Pot already knew this.

[Anonymous Coward]

It's a good point, but coming from Infosys it's laughable

Anon for obvious reasons.

It's admittedly a while ago now, but Infosys are, to date, the only supplier I've ever completely booted off a project in my career for quality reasons. They were contracted to write an application, but the source code that I reviewed was almost what you'd end up with if you deliberately tried to write the worst code imaginable. If you imagine the worst, most poorly-structured code you've ever seen while containing every antipattern ever conceived, it doesn't even come close to just how bad this was.

I cannot for a single second imagine that the LLMs would churn out anything worse.

[Richard 12]

Re: It's a good point, but coming from Infosys it's laughable

Oh, but they do.

LLMs pattern match and predict "likely next line given training data"

That makes them reasonably effective at code review - including finding possible vulnerabilities - because breaks in patterns are often unintentional.

It makes them absolutely abysmal at actually writing code, because they end up outputting mixed-up versions of "common" snippets. If the temperature is sufficiently low you often get a blatant copyright infringement, while if it's higher you get duplicate if statements and nonsensical reimplementations of axle-based transport systems, often involving rectangular outlines.

I presume a lot of that is down to much of the training material being secondary school level "write a bubble sort" type things.