Anybody who has ever done programming professionally in the small scale knows this. Refining the requirements is the job.

In fact, I've never known an industry so keen on levelling its own moats as the software industry. We regularly invent things like 4GL, graphical programming and frameworks and engines such as Unity just to enable more people to do programming. People will happily teach programming for free in outreach programs (I am just one example). No other profession does this. Perhaps with the exception of mathematicians and other fields that are very close to programming.

I could teach an economist enough programming in a weeks that they could write an ERP module, but I could not learn enough economics in a week to write one. If the language was the barrier, we could invent a more effective one. We invent new languages weekly anyway. Having seen how quickly beginners can make things with Unity or Godot, I seriously doubt an LLM agent could improve much on this. Of course, if the job is writing yet another CRUD React app with a Java or Python backend, then sure, the LLM will be very effective. But compared to doing same app in something like Excel or MS Access? Not that much.

>One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be

We have internalized more knowledge than we can explain sounds like the textbook definition of Polanyi's paradox:"Polanyi's paradox, named in honour of the British-Hungarian philosopher Michael Polanyi, is the theory that human knowledge of how the world functions and of our own capability are, to a large extent, beyond our explicit understanding" [0]

[0] https://en.wikipedia.org/wiki/Polanyi%27s_paradox

I think this neatly captures the gap in the article; it’s thinking of domain expertise as static, rather than something that needs to be built/extracted.

It also goes the other way; A a good engineer can build experiments and discover the domain even without an oracle on the team; reading protocols or manuals or specs, for example. In other words, learn to be a domain expert themselves.

Personally I find the most efficient way to learn a concept to be building it; you are immediately faced with your blind spots. AI for sure helps improve cycle time on these discoveries if you use it that way; time writing boilerplate goes to ~zero and you can spend your time figuring out how to answer the real questions.

I do think that we as a profession need to learn new architectural and craftsmanship patterns to make it easier to learn from our code; concepts like Literate Programming which were too fussy for fast-moving teams may end up accelerating in the agentic world; I need to read a lot more code than I write now. But also things like Acceptance Test Driven Design; not new concepts, just newly increased in value.

WRT the native grammar, consider adjective order. Few native english speakers (me included) can off the cuff name the proper order, but everyone knows the "right" order.

https://dictionary.cambridge.org/us/grammar/british-grammar/...

I think the answer is in the second sentence of the article. The most valuable person in this new world (using the author's own phrasing from the penultimate paragraph) is the one who is good at "building a working model of the domain in [their] head".

Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into coherent hierarchies. If this is neither the domain expert nor the programmer, then it must be someone in between. In the old world, this role was called "business analyst".

Having worked with domain experts I concur on the difficult time they have expressing the rules of their domains.

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 think that you raise some excellent points here. I want to dive deeper into what is meant by domain knowledge -- as a I see it. This phrase comes to mind: "Those who know, do. Those that understand, teach." (Google search tells me that it is frequently misattributed to Aristotle.) People who cannot clearly articulate rules for their domain only "do". However, those that can clearly articulate will "teach". Thus, I would say true domain knowledge is the ability to teach that domain to others.

I agree with your point that people “from” the domain aren’t automatically equipped to start AI-building software in the domain, exactly because they often lack one of the most crucial software development skills — being able to (and having the desire to) describe a complex system with a finite set of deterministic rules.

But I don’t think we should be calling these people “domain experts”. I think we should reserve that name for the other group, for the people who truly and deeply understand the domain, the whys and whats and why nots.

> But what they could do was tell him whether the handling of any particular transaction was right or wrong. So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.

This combination of requirements is the business in most domains. Software or otherwise. Codefying different rules and executing them.

> So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.

Right, so the spec is derived from examples, an interactive process that doesn’t require a programmer.

I have found this with (mechanical) engineers. They know what they want to see but don’t understand the underlying details which are more mathematical than the average engineer is able to work with. So the people working on engineering software are often physicists or applied mathematicians.

Yes. The author stumbled on the p vs np problem but with humans. Verification is easy. Solving is the millennium prize question.

That is why coders who learn problem domains are where the money is at.

Works for me.

Already learned two or three problem domains well enough and now it is starting to compound.

This is the exasperating part about learning to speak Spanish using a textbook; you must guess the grammar rules because the textbook won't tell you. So, you use the English rule and hope and pray that it is the same in Spanish, and you'll be right the majority of the time but often wrong. Spanish textbooks written 100 years ago tell you the grammar rules and are more useful than recent textbooks.

> I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years.

This is the part I disagree with.

In a non-agentic world, the expert and the programmer are two different people. If the expert finds a bug in the software, they have to describe that bug, send it over to a programmer to fix, wait for a new release and until that scenario occurs again, realize that their description was actually wrong, send a corrected description, rinse and repeat for a few iterations until the bug is finally fixed for good.

In a world of agents, the expert finds the bug, asks the agent to fix it, realizes that the fix is incorrect because of sloppy thinking, does a few iterations until the feature works correctly, and that's it. Bug fixed; with 10 minutes of work instead of a few weeks.

I had the same problem in air travel industry. Our ticketing officers were never able to communicate how the ticket commission rules from our partners should be interpreted. I ended up adding a test framework, that allowed to add examples and counterexamples of existing flights to each rule, to verify that they are applied the way they'd assign commission by hand.

You described reasoning by analogy, which two thirds of the population does.

Domain expertise matters more than most bootcamp grads want to hear. Knowing how to phrase a query for a specific domain is half the battle.

This is basically the gap BDD tries to close I guess. It assumes that domain experts can't fully articulate the rules upfront.

Some companies use product managers for this purpose. They translate the implicit domain knowledge of those experts into explicit requirements, mostly through interviewing.

I fully agree here. It's also not uncommon to have the reply for specific items be "Ahh, well that is a bit of an edge case see because of X and Y" and then you learn there are many many "special cases" to the point that they aren't that special anymore.

I very much agree here--the true job of us programmers is determining exactly what the problem is. The domain expert will fail because they haven't attempted to refine the details enough, they probably don't have the skill to anticipate the edge cases.

I've spent most of my career working with the same people--even people who have some coding experience but they never catch the low probability stuff. Or even not so low probability: business procedures were that the customer was quoted an all-inclusive price. Try to work backwards, what is the pre-tax amount? Um, that's not guaranteed to have a solution. My concerns get ignored, I go ahead and implement with code that will catch the offending penny and label it roundoff correction. While I'm not sure what happened I think some auditor hit that. I ended up having to walk them through the calculation, okay, what's the answer here? Only when they couldn't solve the problem could they accept that what I had done was the only answer. (The actual odds of such a failure are equal to the tax rate. I had not originally worked that out, just saw success was not guaranteed.)

The domain experts make this sort of mistake routinely in dealing with code. AI won't fix that.

> I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years.

Maybe they need a build a hybrid expertise of "domain" and "software engineering". For example, robotic surgery requires expert surgeons to build sufficient expertise in robotics

Also, noticed a pretty high karma for a throwaway account.

Are we thinking about the wrong side here? Wouldn't the LLM be a super-intelligent financial expert as well as a super-intelligent coder?

I guess the flip side to that is the iterative conversation to develop these specifications is exactly what AI chatbots are good at.

It's also the main reason why very structured AI agent orchestration for software engineering modelled on rigid processes fails to really provide much value.