Been going around talking to lot of old friends in Bangalore, many of whom are either engineering leaders trying to do "ai transformation" within their companies and a bunch of them doing consulting (either independently or have started up). Few very interesting failure modes I am seeing in the transformation journey and why diffusion continues to remain slow across the industry 1. mid-senior identity crisis "how can I merge without reading?" "if the AI will do everything then what is my role?" "everyone is pushing slop, if even I stop reviewing then it will all crash" all good intentioned things, but most mid-senior engineers (4-8 yoe, usually 'tech leads' of smaller projects, care about craft, hold the engineering bar within their teams), are approaching it all too emotionally from a point of loss of identity, and it is preventing them from truly letting go and experimenting and finding the real 'frontier' the frontier is where the limit of the AI capabilities are. you cannot find the frontier if you are too scared to go from cursor/copilot style programming to "jira-to-agent-to-automerge-PR" style systems. yes things WILL break! that's the point - find out where it breaks. 2. LLM vs agent the scariest thing about an LLM is that it can still do (poorly/inefficiently) many tasks that deterministic systems are 10000x better suited to do. for example "parse this json: {...}" yes, sure if you send that to GPT/Claude, it can do a passable job as long as the json is small, the schema is small etc etc. what a lot of 'using ai to solve' solutions are doing is dumping very random shit into an LLM, and in MVP/demo scale examples, it works, and as soon as the firehose of real data from a real world client hits the system, it shits its pants. many "ai native" developers are not truly "agentic" in their thinking, they think they only tool at their disposal is the an ai sdk "generate" call (the openai API call). the fact that to get the best results you have to create a pipeline where there might be some cleaning/parsing steps first, then the LLM does the coginitive load part, and then again there is a post stage for more massaging of the data, calling other hooks etc is not there in their model of the solution. 3. sandboxes/code-mode is still not clicking despite months of discourse on this topic - there is still little movement on this in many people's solution. especially if they starting building something before Feb/March 2026 era, it is all very CRUD-era model of software. the backend makes LLM API calls, has a limited set of MCPs/tools and operates like a standard API server. people are not seeing that for most non-trivial problems to be solved using LLMs, you need to throw the problem into a VM, and run the harness inside the VM itself. many engineers have not worked in this model - spin up a VM which is like a "cooking area" where you just set guardrails for security, but otherwise, you do nothing - just let the bash-based agent rip, is not exactly standard way of building a service in most people's minds, and it is a hard switch to click for people 4. the exec/PM AI psychosis lot's of EMs/PMs/execs and senior people who have not been coding hands on lately, are finding a new lease of life letting their Claude's rip. one little issue is that, they have also not anytime lately been "accountable" for the fallout of code they have written or "responsible" for keeping that code running. so for every brainfart of an idea they have, the most minor of pushback from an actual hands-on engineer, gets met with volatile reactions where they go into their caves with the Claudes, furiously prompt it to build the MVP, and come rushing back out shouting "see if I could make the MVP in 2 hours, why do you think you cannot build the prod version in 2 days?" claude is only giving them the ability to generate tons and tons of code - something they had mostly forgotten having either never had done, or done far too long back. but claude's ability to generate tons of code, doesn't automatically give them back the ability to also become a good triager of bugs, responder of oncalls, architect of systems and refactorer of desings. this creates further crises of confidence and loss of trust between the people who will actually respond/triage/refactor/own/maintain the system and the execs/PMs/EMs who think they know better