Know the trade-offs

LLMs are making software development faster than ever. The question now is whether they are also making engineers weaker. Frontier models and tools can do a great deal but there is an equally large amount of things they still cannot do.

LLMs are great at generating code, but they require the right input to produce the right results. The same problem in two distinct companies may demand entirely different solutions. Institutional knowledge, company context, and the people within it are essential in determining what the “right input” actually is.

LLMs can power through piles of bug fixes and new features, but they will not care about you or your company when failures happen. Only people do. This remains our advantage.

I see many professionals in a “honeymoon” phase with AI because of the speed at which it produces great code - often better than they feel they could write themselves. But, as Thomas Sowell said, “There are no solutions. Only trade-offs”. In time, those trade-offs will become clear.

One such trade-off is skill atrophy. By introducing an intermediary that writes code for you, you gradually lose touch with the details and slowly forget how to write it yourself.

Losing touch with code is not a new phenomenon. Managers all over the world have experienced this. It is not fun when tasks that once felt natural suddenly take three times as long, if not more.

You have experienced this too when forgetting a second or third language learned at school. Two or three years after you stop studying Spanish or French, you can still understand it but struggle to speak it. A few years later, you realise you have almost forgotten it entirely.

Writing code works the same way. You can still understand it after a few years, but the cost of going into details and verifying how it works increases. At that point, a chat prompt is waiting, and you tell yourself, “it’s just this time”. You begin brute forcing solutions to get something working and move on. Unfortunately it rarely stops there.

Prompting your way to success is acceptable when you understand the codebase, or when working in non-regulated environments with limited consequences. However, once you become responsible for code you do not truly understand - especially in systems with real-world impact, “vibe coding” stops being fun. Seeing “You are absolutely right” from the model after proposing an alternative becomes frustrating.

Over-reliance on LLMs may also lead to convergence towards the norm. Recently, the PM I work with wrote a product specification outlining a problem and several possible solutions, none of which he considered ideal. Curious, I prompted a frontier model with the same problem and received the exact same solutions. Yet when discussing the problem with an engineer, he proposed a third approach neither of us had considered.

My immediate thought was “have we simply prompted the same model, with the same input, and reached the same solutions”?

We all agree that deeper technical experience leads to better use of LLMs. But how can engineers remain sharp and technically relevant while leveraging AI without falling into the prompt trap? I can’t yet say for certain but I find Theo’s suggestion - using AI for “research, exploratory work, testing, review” - to be a sensible balance.

Sometimes I wonder whether the fable “The tortoise and the Hare” perfectly captures what is happening to programmers today.

Nonetheless, if your immediate goal is a raise or promotion, AI may well help you achieve it. But depending on how you use it - whether prompting for full features or small changes, copy-pasting blindly or using it as a reference - you must remain conscious of the long-term trade-offs for your career.

Choose wisely.