Happy to be part of "make mistakes and learn" era where trial and error with the help of the technical documentation was the only resort to build something. Stackoverflow and thousands of developers who shared their insights in the platform, deserves a lot of appreciation because they made the trial and error part much more easier and saved a lot of time. Back when I was an Android application developer, I used to spent hours to figure out how a native api work and identify the best practice to implement a particular feature using it. Resources were limited, but we figured out things in the long run at the cost of time and effort.
But the landscape has changed with the discovery of LLM's, a next word predictor that altered the way the world worked. The impact of tools and services that are built on top of LLM's are remarkable. Not only software engineering but also every other domain is utilizing these solutions to work efficiently. It's needless to mention that software engineering has benefited a lot from LLM's and agentic tools. The speed of planning and implementation of solutions have changed drastically, and the proof of the same is evident in the new discoveries we witnessed just by the end of the first calendar quarter of 2026.
The number of such breakthrough's we've had so far is high and it is hard to comprehend the details in a short time span. It is clear that LLM's are being recursively used to speed up research and development.It has contributed a lot to the speed-up discoveries in various fields including in the development of next generations of LLM's. Some of them that made a lot of noise in the industry are :
-
Open Source and Open Weight models
Real freedom is when a developer is able understand the architecture and training details of the model used. All prominent model abstracts such key details from its users. To advance, open source and open weight models are important. What would have happened if Linux was a proprietary software? Huge shoutout to MoonShotAl(Kimi 2.5) and Alibaba(Qwen3.6) for making them open.
-
Claude Mythos
Mythos is the new talk of the town now - like anything this one too have mixed opinios from its users (Mythos finds a curl vulnerability). This model is capable of identifying security vulnerabilities. According to glasswing members,unlike other models existed in the past,this one can actually weave out an exploit from minor unrelated flaws within the system. (Project Glasswing: what Mythos showed us)
-
Turboquant
Tokens costs memory and compute. When an algorithm could reduce the memory footprint, what would be the impact on the industry? (Why TurboQuant Moved Markets Last Week)
-
Gemma 4 ubiquitous models
Large models are not required for most of the problems, this is the reason why we need to endorse the development of small ubiquitous models (Gemma 4: Byte for byte, the most capable open models)
This immense pace in R&D will definitely reflect in all fields which utilizes tech. In this blog, we will focus on the impact of LLM on developers and software they build.
Impact on developers
Developers can become ideators who wears the cap of a product owner, who identifies the requirements of the business and fills the gap between a user and a software developer. Now, problem solving is more about defining the spec (spec-kit, skills.md), while agents does the implementation. Developer's job is to chisel and make the product perfect with the help of prompts, while agents does the heavy lifting.
There are advantages and disadvantages to this approach. Lets be optimistic and start with the advantages.
- Agent based software engineering challenges the traditional seniority based heirarchies in large organizations. Every developer, irrspective of their number of years of experience in the field, can sit in the driving seat. They can envision the end-to-end of a product with lesser focus on the underlying implementation as this is ensured by agentic tools already. But this does not deny the fact that a senior engineer with first hand exposure in buiding and delivering software, has upper hand in navigating ambiguity, making architectural trade-offs, and aligning technical decisions with business objectives
- In most cases, agentic development guarentees a working solution with commentable end user satisfaction and performance.
- It drastically increases the pace of development and delivery cycle. Things which took weeks before, only takes days in the worst case, to reach the customers.
- It provides newer ways to learn things, sometimes the solutions proposed by an llm might be much better that what we thought in the first place.
Talking about the disadvantages, software developemt gets into its peak when we implement something which was ideated. Implementing it ourselves always reaffirms and validates the architectural desicions we arrived at, while designing the solution. Now the implementation part can be totally handed over to agents; coding and debugging feedback loop is something that developers doesn't concern anymore. This is good and bad at the same time. Humans are as good as they repeat an activity. Developers who moves away from the coding and debugging can loose their traction to read and review the code written by llms. This a very concerning problem. As far as human is in the loop of software development lifecycle, if human is to takeover and solve a critical production bug that agents couldn't solve, then developer should be aware of what the codebase does. Developers who have drifted away from programming can face backlashes when such an event occur. Otherwise a developer should never write software at all, instead they should just connect the dots between the modules built by agents, to get the overall architecture working. Looking at the pace at which AI tools progress, there is a high chance that we dont even need to see the code anymore, agents itself will provide us the final product we desired. (Bun moves to Rust, Claudes C compiler).
On a broader aspect, what does it mean by using an external system as our second brain? Lets take a real world example; we consume news from multiple social platforms, we already know that not all of them would be true - but still we tend to believe what is false to be true sometimes. How does is happen? If 7 out of 10 news articles displayed in a platform are correct and validated by the public, then we automatically tend to believe the rest 3 which is false - A halo effect will be subconsciously created within our mind. The same effect happens when we use GPT's to offload our tasks and this is true for everybody who uses these tools. We will scrutinize the results from llms rigorously at the begining and towards completion, we will accept whatever it provides - we simply cannot match the pace at which results are generated and we tend to believe the results are correct. Things get even worse when multiple agents are used in parallel.
We also tend to believe that the solution is built by us - generally that is true because we initated the developemt with a prompt. But in reality the ownership is held by the tool itself - it creates an illusion of productivity. When developing a solution ourselves, we would be constanly making minor design decisions within the codebase - this is how we learn and evolve. On the contraty, with agentic development we would be aware of the overall structure of the solution, but all the nitty-gritty details would be taken for granted by us. Due to the same reason, one can argue that it has become very hard to consider coding as a hobby, similar to aquascaping or painting - what is the fun if we are just observing someone making the stuff for us?! How do we claim that we have built it solely?!
The solution to all these problems is to find ways to utilise GPT's creatively. There is no point in being skeptical about it without exploring the ways to utilise it effectively. These are some of the measures that could be followed for learning and developing in the time of GPT's:
- Follow the old way - Spend free time building POCs hands-on, just with the help of the documentations and articles available online. Let mistakes happen naturally and try to fix them. This approach is time consuming and would require a lot of patience, yet trial and error makes us more confident in the area.
- Use LLMs for debugging - While building POC's, use LLM's to find solutions to fix the errors or exceptions encountered. This saves a lot of time, but there are chances where we just copy paste the error and follow on. If the goal is to learn what you are doing, we might miss the details with this approach.
- Copy and Paste - Ask a GPT to provide the solution and manually copy it to the project. This gives the same affect of option 1 if we understand what we are copying. Learning something new is just one prompt away!
- Use agents, but define the core logic - It is very important that we need to build expertise in the agentic tools available. There is no point in being pessimistic. Even though agents are being used to build a product, developers can still define the core logic of the solution while agents fills the missing parts and finish it.
The take-away from all these options is to understand what we build.
Impact on software commoditization
For decades the industry has been monetizing software based on api usage of its product. Running the product costs them compute, memory and storage usage in a managed cloud or on-prem, on top of which the solution is mounted. In agentic tools era, token is the new oil and commodity. Earlier if it was the cost of cloud and managing developers that companies had to deal with, now they have an additional expense of token usage. Its hard not use agents to build solutions, as engineers are more and more accustomed to writing prompt for research and solutioning, as it is faster, more efficient when compared to googling. Companies, on the other end, will be compelled to subscribe to enterprise LLM vendors due to market competition, the need for speed, and increased product exposure. More importantly, security concerns arising from developers using free GPT tools will drive this shift.
There are only few deep tech companies who offer GPT subscriptions and they control how token is spent (Anthropic beats OpenAI on business adoption). Organizations who consume these agentic tools doesn't have the fine grained control to observe where exactly token is expended and only option that is left with them is to cap the usage per user. Introduction of each new model in the market would be priced more that its predecessor. Token expenditure should become proportional to the speed of delivery and quality of software - more productivity, more PR's, more deliverables, but in reality, for a SaaS company its hard to evaluate token usage with respect to useful features made available to the customers (Uber exceeds its AI budget).
SaaS companies could have many concerns regarding the usage of these tools. It is true that every new model introduced are more capable that their predecessors, but how do we evaluate that the current problem to be solved even require a bigger, costlier model. We expect that the bigger and newer models solves whatever problems we have despite knowing its complexity, but truth is that most of the time very small and less costlier model is sufficient. Should we use a new model just because it exceeds benchmark ratings or should we pick a cost effective model that is good enough for us - still there is a huge confusion in model selection for a task. The next best option would be to self host an inference engine with open source or open weight models - So does every company run LLM's in their own infra and should they have a dedicated Ops team to manage it? and Should evey company have a research team who are capable of architecting bespoke LLM's for the company?
It would be harder to position a product in the market with such fluctuating parameters.
Conclusion
GPT does an excellent job of reflecting our ideas back to us - answering the questions we have in ways that feel deeply resonant. Once we trust the machine, it becomes hard to remember that it is simply a next-word predictor with a set of rules (a harness) that converses back to us. Humans are intuitive beings, and intuition is not always grounded in the factual validity of an answer. We have a tendency to accept everything that feels cognitively easier and that is precisely where the risk lies. AI responses are fluent, confident, and frictionless, which makes them feel more credible than they sometimes are. Agents have the ability to take cognitive load off our shoulders and do the work elegantly. But offloading work to another system should never replace our original thinking. We must remain in the driving seat - with a full, 360-degree understanding of the solution. The moment we stop thinking deeply about the problem, we lose context, ownership, and the ability to course-correct.
Whenever technology disrupts an industry, it is always better to identify its advantages and disadvantages early and make the most of them - rather than resist or wait. The ones who win are those who adopt strategically, not blindly.