Posted by aaronbrethorst 22 hours ago
- is the app is properly deployed - how will the release cycle be - is it secure? - can we run two instances of it without messing up the orders/routes/whatever? - will we spend 5k/month in vercel if people start using it - how will we notice service degradation - if we change the data do we have downtime? how do we schedule that downtime window. - where is the code stored? can the team access it? - how are new contributors onboarded? - does the app use credentials and where to store them? - does the app manipulate or store PII? - if the user refreshes the app does it generate a duplicate order/route/whatever? - if there's an upstream service are we making sure our timeouts are properly configured? - if there's an upstream service are we making sure our connection pool is properly configured? - do we have a max connection lifetime so that middleware like AWS NAT or ALB don't leave us with dead connections in our pool?
I think that makes the point clearly. Also it may explain why software developer jobs are currently on the rise despite SWE-Bench-Pro-Ultra-Magic has been maxxed for months now.
I'm an infra/admin jack of all trades with a comp sci degree and have been a hobby programmer for 30 years. I have a Lichess rating of 1000 on a good day.
We tried doing a chess bot competition (open book, use AI to program it, pull in opening books, end game tables, whatever, free for all) and I absolutely stomped him, but I've only beat him in real life over the board twice in 20 years.
He will beat 99% of random players in real life, and I will beat maybe 20%.
I'm not sure what I'm trying to say, but it seems to me that maybe domain knowledge isn't everything anymore? Or the domain itself has shifted?
For example, I used to do integrations for sports betting sites. AI is going to help with the basics, like understanding the default puck line is 1.5 in hockey. AI is not going to realize that Bet365 changes their API endpoints for each season, so you need to be ready to fetch the updated ones before the new season starts, whereas most other sportbooks have consistent endpoints that you don't need to keep updating.
How much domain knowledge is actually unavailable to AI is going to vary by domain, as will the value of that. Chess is probably one extreme, where all knowledge is public, whereas something like military R&D might be the other extreme where domain knowledge is tightly guarded.
The other things you describe, such as endgame tables, are really more related to the domain of chess-computing, a subdomain of algorithms, and likely something you exceed your friend's knowledge in.
Getting to a high rank in chess isn't about better domain knowledge, is about application and experience.
Should AI make you really good at frontend development?
No, you do not become a really good FE dev from having used websites with AI in the mix.
Why should chess be different?
As we now know it, AI pretty much means a language model and the product of programming so many times is thought to be completely represented by the output of a language alone.
On top of that programming languages are more structured and logical than average, so impact on other less-logical efforts (having more scarce clear-cut examples in the same huge training set) can be expected to be less drastic even if they are language-centric also.
It really is working so well for some programmers so far that that's got to be a big one, and possible to push closer to the finish line than lots of other things. And it really is huge "software" companies that are putting up all the big bucks, dwarfing anybody else who's focusing on non-programming languages, or even more rare, non-language AI.
Almost all the money is being put into their own domain, how else would they have the decades of domain experience to best gauge progress which is still needed, plus get the most positive reinforcement from the underlying math & logic.
There's plenty of momentum and critical mass of people already where if AI does turn out to only be for programmers, they'll be just fine with that if they can just make it more true than it is already. That's enough work to keep them busy for the foreseeable future right there.
Doesn't look like any comparable momentum otherwise, it's like a snowball vs an avalanche.
But OP wasn't talking about solving optimalization problems, but understanding the rules of a business domain.
Okay, but I've always gravitated towards working on tools and libraries and back-end stuff; as much as possible, the domain for me is software.
There are plenty of things which are "trivial" to produce with no moat and yet are still million dollar businesses. Kebab stands. Water bottles. Barber shops. Movers.
The market is big.
This is the moat. It was before AI and still is.
After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.
We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code.
Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.
Not all code has to be efficient scalable code. I know some domain experts that were not programmers. They picked up enough Python or Swift + UIKit (this was pre-LLMs) and their applications are now widely used in their domain. In some cases, they contracted some software companies in the past to do the work. However, they did not understand the problem domain well, requiring the domain expert to iterate with them over and over. In the end it was more efficient to let the domain expert to learn enough programming do it with some guidance from experienced programmers.
Also remember that a lot of domain-specific apps do not need to be huge. E.g. I was once at a factory in the 90ies and they needed to do time-consuming calculations for a particular expensive machine. So, someone who worked at the factory wrote a small program in Excel + I think VBA. This accelerated their work extremely and probably saved them 10,000s or 100,000s in manual labor. It was easy for a non-programmer to write, because they knew all the details of the machine and the calculations, since they had done it over and over again. But it's not a enterprise web app or anything and it does not matter if the program runs in 1 or 4 seconds.
By the way, I also consider efficiency to be a specific knowledge domain, or architecting a very large project. So in the end it really depends on how narrow or wide your definition of 'programming' or 'coding' is.
But mental discipline required to write efficient and scalable code is insane that most domain expertise is feeble by comparison.
I think there is some prestige factor in the background too. Being seen like some kind of code monkey is to be avoided like the plague. Business people really don't value the math savant engineer nerd archetype who just codes and codes.
Highest prestige is always taste and judgment, not correctness and skill. This is why people will also talk about how business soft skills, communication etc are more important than hard skills like programming, math, etc. I think one should be careful with this. On the one hand it's true that career progression is quite dependent on soft social skills, but there are also really hard kinds of software jobs where cognitive horsepower and technical experience are absolutely crucial and soft skills won't save you.
Programming is the easiest part! (c) decade+ experienced senior developers
Coding is way easier.
"efficient scalable code" is just as vague as good code. How are you going to know your code is scalable if you don't understand your domain? Scalability is not something you sprinkle onto code.
Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.
Efficiency is about using minimum cpu cycles or minimum memory or minimum network round trip or more generically using minimum/optimum resources to get something done.
Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughput.
Both of these have nothing to do with domain expertise.
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.
Yes, technically, but note that this entire thing can be anything from crucial to completely worthless depending on the domain.
You need insane scalability for a social network or a streaming service, you don’t need any real scalability for (completely made up) managing a fleet of airplanes or the internal logistics of a zoo.
No profitable business wants to pay you for writing code that uses "a minimum" of a resource. It wants to pay you to find the right balance between resource usage, time-to-market, operating cost, code complexity and probably several other factors.
Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!
Maybe we can grab a coffee.
In fact about half of my career has been dealing with 'domain knowledge at least present enough to get the ticket/epic closed but leads to a lot of tech debt'.
i.e. a good portion of my jobs have involved a lot of a good amount of:
- Review PRs with a fine tooth comb because despite domain knowledge, people are human and can either don't know any better, make mistakes, or willingly refuse to integrate feedback, or worst refuse to double check what the coding agent wrote for them.
- 'refactor this thing because it was technically correct but written so poorly that it leads to timeouts and/or a Manager/DBA is screaming' [0]
> We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
A truly good software engineer is able and willing to learn the domain, but there has to be a way for them to learn. I say that because I've been at shops where various levels did that (i.e. sometimes the company itself, sometimes the team, sometimes colleagues) and I've been at shops where everything is lip service and at best you can only glean from what's in the JIRAs and what you can glean from what people outside of IT say in meetings you are in.
> After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.
I think a big paradigm shift especially in the past 5 years has been that most companies are expecting folks to work to the bone, and it winds up being counterproductive because it prevents anyone from being able to have the important conversations.
Culture is a huge factor in this, I've worked at shops where at the very least you could easily have a side conversation or a meeting, and shops where you might as well sign a change.org petition to request time to talk about it properly.
Still, you are right at the crux; Requirements matter more than code at the end of the day. I've been at shops where a person's definition of 'Correct' meant a feature got delayed despite all requirements being met, because they didn't like they way it was written after they were gone the whole time it got implemented and the rest of the team approved all design decisions.
[0] - Next thing you know you learn about a 'batch process' has %numberOfRecord%*10 inserts, possibly with additional fetches given a poorly designed data model to where it is doing SQL upserts in the most wrong way (i.e. doing a get from the DB and then adding a record to be inserted if not present.) and they keep doing more and more questionable things to 'improve performance' rather than rethinking the data layer's query pattern. Seen it more than once in my career.
Nobody cares about quality, if they can't perceive it. They want practical results. AI will give that to them, to some degree. Most people don't see software as deterministic anyways, so sometimes not working doesn't register as the monumental, show stopping, failure that it would me or you.
What looks like _'expertise'_ may actually be pattern recognition built through repeated practice. I do believe that is what a model can already do faster than humans.
So, to me, we've got to be cautious here in that what this post implies is humanity must strive to be in the 99.99th percentile of domain knowledge to 'beat' the model. This is perhaps problematic.
I do think focusing on judgement is the only tact discourse here, and I do think that is fine. Once we have invariance well-defined and covered in suites of various types of testing strategies, and are focused on regulation, wouldn't that be a more doable objective?
Pattern recognition was exactly my first objective, but I only had kilobytes so language was out of the question.
The machine would ease the burden on me as far as the pattern recognition was concerned, but I expected to continue to do all of the judgment myself for the foreseeable future until someday when I had more powerful computers.
Very helpful to separate the recognition from the judgment, but I still found it best to perform both simultaneously. That was what I would have wanted AI for, to do both if I could get it good enough for reliable judgment one day.
>The code was a transcription of that understanding. Acquiring the understanding was the job.
Well in the mid-1970's almost nobody had the title of Software Engineer or software product manager compared to today.
But "Coders" as a job title were as common as the professional "Programmers", they worked hand-in-hand. The Coders were the ones operating the keypunch machines which took the manuscripts from the programmers plus data from the users and turned it into code on the punch cards so it would quickly run on somebody else's out-of-reach machine without tying it up for very long. Those colossal remote mainframes were expensive. But there was nothing else so what were you going to do? It sucked to be tied to some huge data center though before you could do any programming at all :(
If AI makes some coders of the 21st century feel like they are being bumped down closer to keypunch operators than ever imagined, serving a massive machine they will never be able to own, that would not be too surprising.
>You can now produce the software without ever building the model, and that breaks an assumption the whole profession was organized around.
This is exactly what I said back then, but with reverse angst. I was observing all the professions up to that point in time, almost all of which had nothing to do with software or computers at all. Since actual stand-alone "software companies" were still rarer than hen's teeth. With desktop computers beginning to take hold, Bill Gates and backers like that put maximum effort into getting software recognized under copyright and not just patent coverage.
Next thing you know there were two handfuls of software companies which is still pretty insignificant, but that is exponential growth and it can be quite tempting.
That's when I realized if that keeps up, people leading the first wave of computerization are going to start producing "the software without ever building the model", especially with a lot of professions that require decades of domain expertise which can sometimes be more infinitely rewarding to leverage with each accumulated decade.
If it was going to take decades anyway, might as well do it. The idea that computerization was going to take place using purchased software, without so many companies having their own home-grown programming expertise from the beginning, is what breaks the assumption that all other professions were organized around! That in itself was going to leave a lot of money on the table.
>The domain expert had no equivalent path, because learning to build reliable software is years of work they were never going to do.
I had already spent years learning to build more reliable code than you could generally get from popular software, because reliability is what I needed more than anything. I wasn't going to spend the years of additional work making my frameworks into things that even resembled commercially appealing products though. If I ever decided to go that route, there were going to one day be high-performance teams having well-honed experience in that area if nothing else. Gave me more time to concentrate on other things.
Even though I had a teenage head start in programming itself similar to Gates during the same 1970's, by the mid-'80's it was not only programming but AI too was plainly going to only get more popular faster than I could keep up. I had already started to do a little ML a few years earlier which really worked, but it was expensive and "nobody" around here could afford it once the oil crash kicked in. It was plain to see that "all I had to do" was wait and any domain expertise I could develop in natural science could be leveraged later on if AI gets good someday. I even explored the neural networks of the 1990's but that wasn't going to cut it either.
And here we are.
If I got a wild hair and decided to launch a (non-mission-critical) "product" at this late date I guess I could consider the use of an AI agent not much differently than I would have engaged with a software team once they became an entity themselves. Same business model from my point of view over the long term.
The most artificial thing in the whole timeline is copyright which lots of massive sand castles have been built from, and that is where this language-model-approach to AI strikes the weakest foundation so far, as the tide finally rises too much to be denied.
One big artificial thing gets ugly when confronting another big artificial thing as they're vying for king of the artificial mountain :\
The company I work for is currently trying to accelerate internal AI adoption, and recently laid off people to help force it. As I've written here before, this merely pools accountability (not removing it) and things will break in unexpected ways as people are not domain experts in these new areas added to their jobs.
I wonder if we will see a large reversal in a few years, or if AI will somehow be able to fix this too
Sure it lowers the bar, and some people will design decent things, but mostly these things will become mission critical and broken at the same time.
In the past year we've seen these non-technical analysts become more productive when it comes to developing internal tools, by leveraging AI models for the dev part.
Prior to this, pretty much everything was developed in Tableau. It was the most accessible way for non-devs to build working tools.
Just the other day one analyst in our group presented a tool he had been working on, which was basically a port of a tableau report, made into a more flexible app.
Having worked across many disjunctive domains the value of "expert in domain" is greatly exaggerated. It's not like search engine doesn't exist nor that it cannot be easily absorbed. Quite often becoming expert is as simple as careful reading API documentation for existing, same domain system.
The piece is heavily one sided and don't recognize the problem of low reliability software: e.g. imagine a software designed in a way that it keeps critical piece of data as a global static variable. This will always work for a single user but will leak with two. Make it semi-critical and e.g. a part of profile loading.
Just as non-expert cannot verify if result is correct from a domain perspective, expert in domain cannot verify the output based on the basic principles (data security, safety, isolation, persistence, etc.) or even know that monetary values shouldn't be kept in floats.
Nothing like article claim had changed outside of a false promise of being productive.
Software engineers without domain expertise can fake it with unreliable results and experts without swe skills can fake it with unreliable results.