Agentic Coding is a Trap | Lars Faye

This is a balanced article from an engineer seeing all sides of agentic coding. I found myself reading this and thinking that I agree and disagree based on the thing you are making. Not all code is equal. Some code deserves additional effort and oversight, and other stuff does not. I think folks don't consider that enough. For some solution I think the process that is described here is spot on. For others, I would not agree.

I do think the issue that everyone is seeing but nobody knows the answer to is how to junior engineers learn the hard things. I don't claim to know the answer, but I do know that just like so many other things there was a time when engineers needed to know assembly and for sure the "grey beards" of the time thought it was insane that a modern developer couldn't add some assembly in the midst of their solution.

The abstractions keep growing. Prompts are a new abstraction. Claude generated plans are an abstraction. I think the leap for us is to consider them as much part of the code base as the actual code that the computer runs.

The assertion of Vendor Lock-in though I would disagree with. This line:

You know how much your employees cost; you have no idea how much your token costs will be day to day, month to month, year to year. If your entire team is using agentic coding as the default, your expense account will need to remain highly nimble.

Say that again but instead think servers. It works. "You know how much your servers cost; you have no idea how much your cloud costs will be day to day". That was an early cloud concern that we worked past. However, to get there we had to learn how to measure value. That to me is the giant challenge in front of us. How do you measure value creation over token consumption.