Domain expertise has always been the real moat

Once I built a little domain-specific language for them, that was tested against old jobs to see if they contradicted the past; it was a nifty project and since then I am convinced that DSLs are underrated as a way to encode expertise.

I believe there are domains that are very well encoded. The model very often can know that a shift can't be longer than 11h and if you ask an agent for scheduling software it can surprise the developer by encoding that rule.

Both domain knowledge and coding skills became cheaper.

It might depend on the domain. Highly regulated domains like finance have entire books around how they should work.

However, I agree that verification skills became more important in both areas. A domain expert needs to catch 12h work shifts and experienced programmer needs to catch when the LLM accidentally put a route in a section that doesn't require authentication.

Both require some kind of harness and automatic verifications methods.

This has always been the most valuable person. A skilled software developer who is also deeply experienced in their target domain is untouchable. They can always move the ball forward at some rate, assuming they're making any attempt at all.

It takes a really long time to absorb some domains. The most painful one I've experienced is the banking industry. It took me a solid decade in the trenches before I felt comfortable running a status call with a bank's operations staff without a babysitter.

I like to think of this as a sort of cube of capability. The X axis is technical expertise, the Y axis is domain expertise and the Z is physics (ai/tools/computers). The volume of this space is what we are interested in. Scaling up to a wild amount of AI capability with the best developers on earth (infinite x-z plane) is still going to perform like shit (zero volume) if you have no practical domain expertise available.

Specificity, availability and recency are perhaps the most important parts of domain expertise. None of these tend to be in ample supply with frontier language models. You can get a general sense of how a bank operates from chatgpt, but the FDIC would take over your bank in the middle of the first night of operations because you didn't learn the secret handshake (how to interact with your customers, competitors, regulators, etc).

If you believe Claude makes you a good engineer and you previously weren't, I am saying that's not true and you still are not a good engineer even with the latest-and-greatest Claude model.

The difference is between "helps" (in your comment) or "you are". Sure, it helps a good engineer do more, do better, etc — but the thread was on being a good engineer.

But I'd also claim that these things fall on a spectrum. At the extreme end we have exchanges and HFT-like trading systems, where absolute accuracy and latency are not even constraints but industry fundamentals. At the other end we have "toy" applications that handle tens of requests per second, tops.

Scalability problems are definitely near the extreme end. Only instead of raw latency, you get to deal with complex failure modes, throughput, capacity problems, read amplification and thundering herds... all the while being constrained by available CPU cycles and bounded memory.