Where will LLM coding take us?

Been writing small posts on how LLM based coding is evolving and how it will impact the software industry.The posts are aging so well that by Feb 2026 the markets and public are already convinced that LLM coding will make hand crafted code thing of the post.Thanks to anthropics claude releases.Hand crafted code might become an artistic pursuit even or just a teaching tool.

But where is taking us?

The industry : Would benefit a lot , now that we can ship out software faster than before . This also takes the pivot of success back where it always belonged; that is having superior ideas and executing it well till production.

The code : Perfecting creation of structural code is something that LLM based coding approaches have already demonstrated that they can master well.By now people have also demonstrated that even the intentional part code can also be crafted with LLM based coding approaches.
That leaves us with only the bare bones part the software,which is the code of business rules. The hard part of business which only we know .The best example of such code i could think of was how fortan programmes were written and used .Just the exact business rules sans the I/O or hardware or framework considerations.

(sample fortran code , generated via , well 😉 AI )

Individuals : The spot where our jobs were standing has shifted now.Instead of being the person who wrote code by understanding business from someone.We now have become the person who understand business so well that we can now use LLM coding approaches to fulfill the effect business needs.This was always why IT department existed in the first place (hence the fortran analogy).Is this making all of us business analysts ,not really but it does make us software product owners.A title that needs to be coined now.

Job losses : come on, ask any ceo, there is so so much business always wanted to do and achieve but could not due to to lack of software delivary speed.That constraints is removed now.

However: Transition periods are confusing,chaotic and not time bound.That we need to bear.But a total and complete job losses for us,No way.

What i wrote in Jan 2026 new year:

by the time 2025 is closing and the question on will Coding LLMs/Agents/IDEs replace human programmer? gets aksed ,i am at ” It might actually” moment.

Few quarters before i was at ” may be lets see”.

Thats the amount of progress state of the art has made .
Based on the report you read and the date of it ,some 40 percent of code and 256 billion lines of code has been outputted by models. Forget about the impact but such numbers means it is a large scale training and human verification that has already gone back into the models/to the labs.

With more focused optimizations from the AI LABs in the model architecture and deployments 2026 especially by plugging in some knowledge representation and knowledge priority/ranking might close the year 2026 on “Ah it happened”.

ps: there have been many shots taken at eliminating the programmer over last 4 decedes (really,its that old of a dream ).
These attempts tried visuals, formatted config,drag and drop and even document based approaches. Additionally the design based approaches like annotation and injection also kept on happening.

But the “so called” ability to reason offered by LLMs is breaking past the totality barrier of code generation from specs . My best bet is models becoming runtime aware is what will be the last finishing touch to the masterpiece.

feb 2026 :

Most of the buzz on llm coding is about how fast and easy it was for a non tech person to write an app or software was.At times we hear personal experiences of using llm coding by old techies like me .

But we hardly hear anything from people who sell software itself as the commodity!
So, the likes of android or spring or angular or chrome have a huge builtup of code complexity in them.They also have competing and conflicting features and a huge backlog of features they would have loved to implement yesterday.

The real and more believable metric of impact of llm coding will come from these places.If they are able to ship bigger feature sets faster,it would be the gold standard for productivity measurement around llm coding.

This also raises another question. When llm coding is so powerful why would we need their framework at all? would it not be easy to get your own curated framework based on your needs and use it. The picture is much darker for maintainers of smaller specialized libraries.

vibecoding or llm coding as i call it, is going to have its first evolutionary prey-victim soon. Cambrian explosion are beautiful and brutal at the same time.

Will Code generating LLMs replace programmers soon?

By the time 2025 is closing and the question is whether Coding LLMs/Agents/IDEs replace human programmers? gets asked,i am at ” It might actually” moment.

Few quarters before i was at “maybe let’s see”.

Thats the amount of progress state of the art has made.
Based on the report you read and the date of it ,some 40 percent of code and 256 billion lines of code have been outputted by models. Forget about the impact but such numbers mean it is a large scale training and human verification that has already gone back into the models/to the labs.

With more focused optimizations from the AI LABs in the model architecture and deployments 2026, especially by plugging in some knowledge representation and knowledge priority/rankin,g might close the year 2026 on “Ah it happened”.

ps: There have been many shots taken at eliminating the programmer over the last 4 decades (really, it’s that old of a dream ).
These attempts tried visuals, formatted config, drag and drop and even document based approaches. Additionally, the design based approaches like annotation and injection, also kept on happening.

But the “so called” ability to reason offered by LLMs is breaking past the totality barrier of code generation from specs. My best bet is that models becoming runtime aware is what will be the last finishing touch to the masterpiece.

I created my LLM from ground up, you should too

Edit ,based on the feedback: Building a car and building a Ferrari that can be sold in showroom are 2 diff things . Here are links to learning resources Stanford class , Karpathy and Rashcka

LLMs have moved on since ChatGPT

As an AI Architect with production level experience with AI/Neural Networks and regular reading of various research papers in the field, the arrival of ChatGPT didn’t stun my circle of technologists as much as it did to rest of the sector.

The initial use case in generative AI was focused on using it to literally “generate” insights via prompts. It quickly morphed into a general purpose toolkit for most routine (or shallow) inferences.In a way it was sort of a Java or Windows moment for the technology field. This was the era that felt very comfortable to someone with prior hands on tensors.

The Cambrian explosion of LLMs

By the time 2024 ended, the default choice for GenAI projects wasn’t always OpenAI. There were many LLM companies that shipped many versions of LLMs with different architectural designs and sometimes shipped an internal mix of experts. In the larger field of LLMs, the scientist would still discard such differences as more differences of the same thing. But if one is crafting solutions around LLMs one has to account for differences in modality, reasoning , pure chatbots and so on. Not to forget their parameters and tasks they were specialized in ( and beat some benchmark for ) and evaluating them/output.There is also enough business traction in moving to domain-specific models . All of these demanded a personal experiential look at LLMs.

Hands-on learning of LLMs

As such, there are multiple universities and experts who have amazing courses and materials on LLMs.My search zeroed in on the course by Stanford and the material by Karpathy and Rashka.In fact, one can ask ChatGPT to generate code to create one’s own LLM and it would give you 20-something lines of code to do it . But what insight can it provide?

Learning path and building knowledge pyramid

This boils down to first mapping the knowledge pyramid for LLMs as a field. I got this image created with the help of ChatGPT as a reference, but one should define their own based on where he is starting and how far one has to reach (there has to be an upper end).

Another aspect of my learning approach is to read 2-3 books on the same topic. And then move to read/watch/code more along the knowledge pyramid/path. That ends up being 10-12 books or equivalent of watching/coding for each new technology wave and a few months.

As such, each book has its own objective, so when books are titled as “from scratch”, “hands on”, “head first”,” in production, or “deep dive” etc, it makes sense to read the table of contents or preface. That can give you a good idea of the journey the author will take you (and what remains for you to do on your own).It is also useful to read the book cover to cover, including the references.

For my learning style, I wanted to be guided by someone who could take the learning from a blank slate and build on it, like how the LLM state-of-the-art was built. My approach is also to type along, run and experiment. This is where Sebastian Raschka’s material on LLMs worked best for me.

Building the Actual, not a Large Language Model

Building from scratch approach meant that I had to literally start with understanding transformers, choose text and convert it into embeddings, code attention and then move on to multi-head attention while experiencing the why of it, normalize the layers and code my own GPT model. This version just allowed me to chat around the text I trained it for. But the real intention was to see how everything I did leads up to and affects the output rather than saying look, here is my LLMs”.

I then learnt to add depth by evaluating the generative output and instruction, fine-tuning it (and LoRA). This was done by downloading GPT2 and loading/using it for evaluation.I also took a detour with Ollma since I wanted to use a few mode models for evaluation and see the minute differences.

There were 2-3 variations of my model that I fine-tuned for classification and also generating my riddle version of output (remember 4th standard kids inventing their own riddle/cryptic languages for speaking, that thing).

My most fun moments were experiencing the epochs and watching the output of the print command on the model object(this is real fun, do it). The code-along approach also gave me first-hand intuition around tuning and parameters.

The most frustrating aspect, which is also a reality check, is that debugging the mistakes is very tough. Not the syntax one, but the ones related to PyTorch and the attention overlap area.

Rashka has been very generous in mentioning additional material for the curious minds. For someone like me who is looking for a wide and deep understanding of the craft, taking detours to DPO and Bahdanau attention added to the joy.

What next

Personally, I went on to spend some money on Google Colab and try it all out at a little large scale/TPUs. But that’s as far as faithful learning goes.

My friend Kamlesh has given me a target to fine-tune my post-trained LLM and beat the incumbents on one of the benchmarks :).Depends on my weekend time and budget, tough. Moreover I and Kamlesh, have a history of big ambitious aims. Last year, we wanted to build a vision model to read documents in MoDi script ( later, IITKgp took up such a project with the institution we were to approach ).

As such, there are not many corporations that will be building LLMs of their own and beat the AI labs.

The amount of data needed to give an LLM commercial meaning is bigger of a problem than server and talent cost. There is, however, a case for creating domain LL models as the optimization cycles in the field accelerate, and things become cheaper.

While I wait for the river to flow in its natural course. The most certain thing in 2026 are :

1. We shall be building a lot of agentic stuff for production.

2. …Build more solutions around LLMs

3. New LLM architectures, their specializations and runtime costs in 2026 will look far different than what we saw in the last 5 years(better, I mean).

4. You and I will be crafting commercial solutions around LLMs and AI. Something that AI labs don’t have an interest in, domain expertise and commercial standing for!

So the learning will continue ..

Chatbots before LLMs

Designing Bot frameworks

In the era before LLMs, building a conversational agent meant ….one had to literally come up with sample phrases so that the Engine could do the Named Entity Recognition. Doing this by ourselves was limiting by definition as each person would have a limited range of expression. In that era, there were also tools that generated sentences if you gave them the base activity as input.(Now that we have experienced LLMs, this sounds funny on multiple count, but it used to work). (The era before production-grade NLP was even weird, i have documented that in an earlier post . )

This is also the era when a formal framework for chatbot interaction did not exist. So we ended up building our own framework. We had to debate the fitness of different NLP libraries (Stanford vs opennlp etc) and debate about their accuracy and code framework capability around interactions/invocation. In one case i was so frustrated with NLP that i designed a framework that would allow users to issue commands instead of chat by typing and we also had autocomplete/type ahead added to it . Like how you type elaborate commands on Unix, but imagine the typing experience of Google search for this. We were able to do this with some good keyword-parser-functional paradigm. And not to forget a brilliant developer with me,Nehal . But the momentum for a formal chat-style bot was huge and frameworks arrived soon.

Designing with chatbot Frameworks

Again,a debate will unfold about the chat agent framework selection. Most of the frameworks had similar capability around the core NLP and invoking services part but they had marked differences in the “flow” aspects, voice vs text capabilities and so on . This madea huge difference when the conversions we were supporting had multiple end states or conditionalities. The implication of this statement is that when we first did our chatbot in 2014/15 , the Alexa one the field of conversation design was not acknowledged (Alexa wasn’t available in India then, we got it from us). It was a few years later, especially when the commercial use cases came along, that the User Experience of the part of the chat interaction became mainstream/part of project work (Interaction Design) . Bot discovery and interaction design are useful and important even in the agentic era.

Getting the chatbots working

Once the engine of the framework we selected and trained would determine the action, I would write and wire handlers to do the processing.It quickly evolved into a chain of command pattern cum workflow or some sort. Giving rise to all sorts of integration issues.Message transformation, Errors, Retries, Auth and so on. Some of the frameworks had built-in capability to chain conversational flows (and pass variables/values around ). Most of them had some take on retries and how long the conversation can be, but it had to be discovered than being documented.

And then there was a user.At time, he would be technically disconnect from the chatbot, so we had to maintain the whole conversation state in the database. Sometimes the follow-up step in the processing needed more inputs from the user to I had to create a local and global state for the whole interaction to be recorded.

In some use cases we had to ask the user to upload receipts, which were processed by a vision model.And guess what, the image upload and processing could take more and varied time for my chatbot to remain active.So we keep some keepalive and sweet nothing “status… updating…” going to the user,to fool the whole system. Moreover, the framework chosen didn’t have native support for this sort of outside call, so everything had to be bundled together.

In another use case, we had served him content based on a help document.This had to be done with a combination of a search index in case the document repo was too large.In case of a structured FAQ one of the engine ,NIA had built in the capability of mapping queries to document keywords (density).

As a side note , many engine had some capability to detect obscenity that sufficed.PII interestingly panned out in black and white in many cases (due to the domain and use case mix at that time).

Voice Video and Human agent handovers

The voice based chatbots had a different set of additional issues.The engines from AWS and Google had built in ability to prompt for the question again if the pronunciation wasn’t clear. At times, this ended up in multiple retries/pass at the same handler so it had to be taken care of (since not all services were idempotent ).At time, the user would totally rephrase the ask, which would throw our design off guard .

Another fun aspect is that as Alexa evolved into a voice device with screen, we suddenly had to take care of the visual aspect of the interaction. Multilingual support was out of the box, so life was cool .

Video bots were a different thing to handle. Out stuff didn’t make it to production but the idea was to emulate a human face with expressions (confidentiality etc etc).It was pretty impressive for that time .

In one of the case, we had to handover the interaction to a human agent based on the predefined scenario.It was a straightforward integration to another system with some adjustments to timeout. But when the requirement evolved into passing the whole conversation to a human agent ,we realized that we didn’t have a handle to chat interaction that is provided by the framework! So I logged them as passed it on. That eventually led us to design another product around chat interaction analysis/insights and designs and it went on to (then ) compete with chatbase product.

Some notes

When we select a new technology or framework, it’s best to adapt to its way of doing things. However, when the field is new and evolving, the capability mismatch can be huge. In many case,s when it came to call/orchestrate service calls, my experience with traditional banking development helped me handle the issues with ambiguity, state and performance better than the chatbot native generation of freshers who looked towards the state of the art for solution.It also mattered because most of the recommended remedies around these problems were to use some sort of ESB or wire RPA somehow.I had found them out of sync with spirt of chat interaction (Now that we have LLMs to reason, plan and orchestrate them, i feel validated with some sort of emotional closure) .

Later, when ChatGPT happened and we moved on to RAG and Agentic tools,it felt like I was remaking the Spiderman movie Franchise for the third time. The story from there on in next post.

Embracing the Weird Stuff :becoming AI Architect

Weird Stuff that added flavor

As any good technologist has new “weird stuff” knocking on the door while he is focusing on some other technology. This is also the theme of how my resume got built.

Python was the first programming language I started my career with. At that time I was working on code generators,compiler switches and other “weird stuff” while my friends were working on struts and j2ee. So with much effort I moved to those technologies.Working in banking domain in mid 2000s we would create jobs to facilitate what was then called as business intelligence.These were early ancestors of data cleaning, aggregation and summarization that was done via code and service via ui. It didn’t feel amazing but it was work so we did it.

Enter ChatBots

Cut to 2009s I was obsessed with JavaScript ,Spring and whole SMAC buzz and then another “weird stuff” came my way . There we were building a chatting bot for relationship managers to support the internet banking users .I used the IBM SameTime stack while my colleagues used MS stack. Out bot could do basic chat and then allow screen sharing and video calls.

Post 2010 while I was chasing Angular ,microservices and my Ethical hacker certification, another “weird stuff” called Hadoop came along. So there I was working on MapReduce, Storm and Spark. We had do some Data Science work using Apache’s MLLib. My background with BI allowed me to work on it but converting beautiful data structures to some numbers and flags didn’t seem like calling to the programmer in me 🙂 ,so I was very happy when Data Scientist joined our team. By this time it was clear that DS was the hottest job of the decade but I had moved on to Node and Dockers of the world and then another “weird stuff” called R came along. And again i was supposed to build a chat application .I was so angry to have my “When Harry meets Sally” moment that a wrote a blog post against chatbots 🙂 (here).

ChatBots strike again

It was by this time that the role of AI-Architect was coined ,brining me peace .So I moved on to a projects working full time on AI and Automation .Our projects had working going on neural network of all kinds and all of were hands on. But industry had some other plan .A “weird stuff” called a chatbot came knocking on the door .So there I was building chatbots on multiple frameworks.We had Alexa,Google’s Dialogflow,Amazon and IBMs stacks and open source framework called RASA. Not to forget mentioning our Inhouse AI Studio/Chatbot solution called NIA that my friend GuruPrasad was developing .

This was probably the Jurassic age of bots .

Have LLM use cases platued

This is the spread of use cases of ChatGPT usage. What is not evident from the chart is that people didn’t really ask/need an LLM to do it.
Most of the users would be totally cool to have one app for images, another for summaries, another for coding assistance and just another for music.

( The chart was created by asking ChatGPT )

So long the features and cost are reasonably good, most of users won’t even care what’s powering them.

The everything-everywhere-all-at-once nature of LLMs signifies that their builders have been successful in discovering use cases around the powers that GPT gave them.
This is also the game where feature parity tends to plateau very soon. Ask anyone who has developed a successful consumer-focused mobile utility app or look at your own mobile app installation history over the last decade.
While there is always some buzz around the benchmark, the latest model from some company has beaten but 5 years into LLMs, the real question we need to ask is does the end consumer notice or even care ? Especially the average retail internet consumer? (where the market capitalization lies 🙂 )

Which is to also imply that for end internet users, the craze or utility of GenAI might have peaked as novelty and is taken for granted at par with you mobile phones.
When was the last time did you really felt the difference between version 10 and 11 of your mobile phone?

Ah LLMs ….

PS: 60% of paying chatgpt users are enterprise

Podcast : AI threats and Future outlook

In this podcast in Marathi language hosted by Omkar Dabhadkar i spoke about hashtag#AI . As such Marathi language is spoken by 80 to 100 million people but when it comes to Artificial Intelligence we did not have not-dumbed down content .
In this video i spoke of impact of AI on society in general and IT jobs in particular .The discussion also touched up Indian efforts in fields of AI , nature of Indian IT industry, Indian startups , the need of different skilling that AI will enforce upon freshers and the remedies colleges can take . We ended up also covering Gen-Z and my optimism about them .
https://www.youtube.com/watch?v=A-3CWRoQQnY

Wait but why High Agency ?

West’s rediscovery of Asian flexibility.

Sharing this very good blog by George Mack. It says that having an agency might be the most important theme of this century. There are people who will get stuff done, done right, no matter what. That is the basic theme of the blog. It is a very well-written blog, so please read it for the pleasure of reading.

From his notes, it looks like the blog was inspired by Tim Urban of Wait Buy Why Fame. Another very articulate author worth investing your time.

However, reading this kind of author sounds very funny to me in my Asian mind. Most of what they write is very basic human nature. It’s just that they write them in every detail, laying out each and every factor that goes into shaping individual or group behavior. Some people call it first principal thinking. But most of the time it is detailing human behavior in a bottom-up conceptual pyramid fashion. That is great articulation but hardly first-principle thinking.

I get a similar feeling when I source my books on leadership and Team development after reading HBR. The books on influence, candor or gravitas are fine books, they do offer nuanced details. But the central theme of what they are attempting has the same characteristics. Telling the dynamics of human behavior as if its been discovered for the first time.

For someone who thinks that the ideas or ideals they have in their mind or the ones they read in a book or taught by someone actually shape people’s behavior, this might sound very enlightening.

But for someone from a country or social background or exposure to poverty, deprivation, and struggle for upward mobility most of this is very obvious.

Since I don’t live in the USA I wonder if people are actually living in a social monoculture, away from the struggles of the hunter-gatherer level of life that give rise to the need for such blogs.

Also when I look back at the picture I got of the USA when I read books like Gone with the Wind on popular culture or 80s hit book on leadership called What They Don’t Teach You at Harvard Business School, it didn’t feel like it was a society, that needed basic human nature to be detailed out in such an intellectually laborious manner. (Just to be fair, sometimes Gen Z in India also gives me this feeling ). Maybe we are dealing with people grown in Flowerpot equivalent of social environment.

https://www.highagency.com

Work Hours and a GenZ workplace.

The 8 hour norm

It was in the 1920’s decade that Ford realized that for optimum productivity labour well being is important. That’s the beginning of an 8 hour work day.
Between 1920’s and 2020’s a lot has changed in terms of our expectations from life our social relationships and most importantly our ability to focus on this.It doesn’t need a social scientist to tell that in an environment full of notifications/distraction and huge amount of emotional overload caused by media and news consumption the 8 hour work day itself is a mirage.

The missing link

The second point a lot of us miss on the 8 hours workday movement is that it was optimal for assembly line setup. Software or creative work or sports are not really the kind of professionals where repetitive, mentally less taxing measures of work,output or productivity can apply.Its for these reasons many good companies offer recreational facilities, mediation, greenery and stuff like that at the workplaces.
Many studies done on actual productive work done by software professionals record 3 to 4 hours of meaningful work. That too happens in bursts of 40 minutes blocks.
The rest of the time is spent on animated,less brain consuming stuff.But this is also the beauty of the human brain.While we can do brain intensive work for hours together the slacks not only recharges the brain but it also fuels some creative, lateral reflection on the task at hand.So in reality the slack is feeding into the performance we do in the 3.5 hour productive zone.

Realities of a Gen Z workplace

However a lot of the above studies have become little outdated with GenZ entering workforces.Recent article on HBR type of publications are saying that GenZ’s need for direction,purpose and connection might have shifted the niddle from 3.5-4 hours to a lesser number.In post covid world,i belive even earlier generations might have slightly lesses numbers when it comes to median productive hours.

But,most of the software industry is still stuck at 8 Hours of continuous office activity as a measure of productivity (read again).The outsourcing shops add +1 hour to this . And worst still some old executives call for 70-80-90 hours work week as a regular feature of the Indian industry. Not only is this demand out of touch with research or productivity but it is also heavily out of touch with how emotional of an average indian family men and women operate.

ps: too lazy to locate and cite the source studies.Work Hours for GenZ workplace.

Give me something Quick and Dirty

Give me something Quick and Dirty !?

That’s one of the most common statement that gets good engineers agitated .

It used to disturb me the most when I was a young Architect .But with experience now am able to understand the situation from where this statement originates .Once you see this it will also help you feel calm at workplace by not feeling Us vs They conflict or feeling that your craftsmanship has been questioned .

Here is where it originates

Clarity and certainty are the two most important things that Managers/Directors get asked about . The world will look like heaven if software engineers could given their managers certainty that the job will be done with quality and on what-time . And guess what , this almost doesn’t happen .

So the second thing that manager will seek is clarity . Are you past the roadblock ? what could he do to help you ? and so on. And finally it again comes down to : the next certain date of delivery.

The world of the software engineers

This is in stark contrast with the world the software engineer. To begin with there is lot of ambiguity in the requirements .It has always been there ! There is also lot of interdependency with everyone else’s work . And on top of that there are all the patterns , designs ideals and cross cutting concerns one need to take care of . This is one of the main reason we all could write solution to our LeetCode algorithm problems in a near predictable timeframe but we cant be sure of when our teams can finish the project .

The issue oftentimes is that we as software engineers are poor at communicating all these dependencies that we feel and know .Hell we even expect “them” to know it beforehand !

In great teams there are individuals or mechanisms that help developers verbalize and communicate it .But it is not so common .

What Quick and Dirty actually implies

This where the Quick and Dirty comes in ! The manager ,pushed to the walls of deadline is asking you.

1. Can you please do the most direct code to the requirements , the design ideals can be applied later .

2. Make working assumptions on the missing pieces .

3. Eliminate the dependencies on others to the maximum extent possible .

4. Look for something already available or even an alternative approach.

5. Brute force is allowed instead of elegance (for now).

6. Do not produce buggy or insecure code .

So the call for Quick and Dirty is really a call for software engineer to move from craftsman’s role to the role of savior ,communicator and negotiator (bargainer if there is a word like that ).

What has been your experience with the call to Quick and Dirty ?Did you avert the crisis ? Did you bargain of extra time to make everything proper later ?

ps: What happened to the work of Tech Managers you may ask ?that in next blog