One little detail. The models are already pre trained on similar system implementations. Likely whatever you are building has been built in some form or shape in the past and the ambiguity is resolved by someone in the training set.

I bet there were textile workers who would have written articles like this if the internet had existed back then.

Good post! Also, in my opinion, domain expertise is actually more interesting than pure coding ability. Coding, for me, has always been a means to an end. I'm equally happy with a spreadsheet if it solves my problem, and in fact I hate most apps.

“The hard part of writing software has never been the writing.”

I’m tired of these endless articles on HN about software engineers trying to reinvent their identity while trying not to lose touch with reality.

One way of dealing with LLMs is to deny the skill level of LLMs. Claim they can’t code as well as you. This excuse works to a certain extent but it also fails because not only are their multitudes of cases where the LLM IS intrinsically worse than me… but there are multitudes of cases where it is better. So this excuse cannot be universally true.

The other way is to claim software engineering was never the hard part of engineering and that other things were harder and that was always where your primary skill was located. This excuse is also idiotic. First, Software engineering is hard. It is genuinely not something that anyone can pick up very quickly. Second, all those other “skills” like “domain expertise” are STILL targets for the LLM. It’s not like the LLM exclusively is only good at software.

Just face the goddamn truth. AI is on a trajectory to dominate. That’s what all the trendlines say. It’s not currently dominating, but it’s close, and the trajectory points to an endgame where it is fundamentally better. The trendline could be wrong but the trendline is the best quantitative predictor we have and it’s been trumping all the half baked theories on HN where people were claiming self driving cars would never happen and AI could never code. HN was historically wrong… the trendlines and the VCs who made those bets have been right. So who’s the bigger idiot? Those VCs creating the AI bubble or HNers who have been continuously wrong about everything? (Minus crypto, HNers were right about crypto).

If the trendline is true our skills as engineers not just the software part is on track to being dominated by an artificial intelligence. The tools trivialize your skills until all the moats are gone. Not only that… AI is becoming better at art. Poetry, writing, paintings, music… AI shows us how trivially reproduceable all of it is. That is the truth. We aren’t not unique and all the meaning behind being human is just an algorithm. It’s all reproducible. Even your self delusional attempt to deny and delude yourself away from these truths is predictable. I can see someone formulating a retort right now.

Have you considered becoming a residential electrician? Good job, pays well, lots of problem solving, and it won’t be replaced with an AI. I’m serious!

I have. Or general well rounded construction worker who knows how to build all aspects of a house. A full stack builder.

Have you?

I’d go with physical therapy! Or something else that’s closer to humans and health. “Problem solving” becomes that much more tangible and directly meaningful to another person

chatgpt can already do a big part of this job since most of the "therapy" needs to be self directed. So consult the AI and have it tell you what you need to do.

You cannot be serious surely?

Why do you think people get trained by a PT in person? Its not simply training - it actually goes well beyond into the realm of 'wellness'. man you are a certified bozo.

Good comment but I think the timelines are not clear. Humans are an algorithm. This was true before AI. In certain domains (playing chess e.g.) machines have already surpassed humans. Humans still play chess though and chess is more popular than ever.

I still drive my car and self driving cars have yet to displace human drivers. I think the sentiment on HN and other places when Google started talking self driving cars circa 2009 is that it's harder than it looks. Typically the first 80% of progress is easy and the rest isn't as easy. We're almost 20 years after a "pretty good self driving car" and we're still not at "self driving cars outperform humans under all situations".

Today humans use AI. You can't fire up Claude and ask it "what do you want to work on today". The amount of context we have as humans is vastly larger than the context LLMs have. If you give LLMs vague context they're completely lost. They are mind blowing in many ways but they are not anywhere close to AGI. They're also not close to being able to build complex software only guided by someone who has no idea what software is and how computers work. They can do some of that but I've yet to see any major successful piece of software built that way. They also consume vast physical resources to get the job done.

Before LLMs I think it was a given that at some point we would have AGI that's smarter than us. Machines we build aren't constrained by the biological constraints we are subject to and can evolve faster than we have. But when that's gonna happen, whether that's actually LLM-like in architecture, and what things will look like once that happens, are fairly open questions at this point. In the mean time LLMs can certainly generate a lot of code and we can use them to build more stuff.

Good comment but I think the timelines are not clear. Humans are an algorithm. This was true before AI. In certain domains (playing chess e.g.) machines have already surpassed humans. Humans still play chess though and chess is more popular than ever.

It was always true even before AI, AI just makes it more evident since Transformers are LITERALLY an algorithm that produces content nearly identical to content humans produce.

It is premature to conclude that someone is wrong and will ultimately be replaced, as the final verdict on LLMs is not yet in. In fact, recent trends show rather negative outcomes. Multiple analyses continuously indicate that recent layoffs are driven by the normalization of the post-pandemic bubble and economic recession due to wars, not LLMs. Companies are merely using LLMs as a convenient excuse to frame hiring freezes as innovation. Furthermore, many companies are reconsidering LLM adoption due to cost and efficiency issues.

You claim to be rational and logical, but your argument completely lacks substance and is just full of highly subjective claims. Your 'prediction' is closer to astrology than actual forecasting. Sure, prophecies hit the mark by chance every now and then, but that doesn’t prove the person has any predictive ability. That is precisely what your argument looks like: completely confident without a single piece of evidence. To top it off, you totally abandoned reason and logic in your last sentence. Saying that anyone who disagrees with you is just deluding themselves and that you already know what people will say to snap back is exactly the kind of stuff a cult leader would say.

You're completely giving up based on some strange delusion. I don't even blame you for that. But it's genuinely ridiculous how you use it as an excuse to attack others and act all smug while pushing your defeatist arguments.

This article is wrong. LLM's encode all the domain knowledge you could possibly want. As a software dev I can query an LLM, become a domain expert in a short amount of time, and then code up a solution. If people think their niche is safe from automation, think again. Even the people who think theyre the masterminds at the top.

Edit: Yes "expert" was too strong a word. Proficient would be better. A lot of the barrier to entry in a field is just not understanding the domain.

You might /think/ you've become a domain expert, but you haven't.

I won't over-generalize here, because maybe your statement is true in some cases, but I will provide a counterpoint: this is not true (in my experience) in real estate title insurance and escrow services.

I've consulted for and led large teams for real estate title insurance and escrow companies for many years, and the domain expertise is so incredibly deep, nuanced, and multivariate (especially depending on jurisdiction) that building valuable and viable products in the space is incredibly difficult - before LLMs, and even now, with LLMs.

Without getting too deep into it, I'm pretty bullish on AI (and have been very close to it and deep in it for a long time, while also very apprehensive about the effects it'll have on society), and I can tell you, from extensive attempts from myself and many on my teams to leverage the latest frontier LLMs to bring deep domain experience to bear to help drive valuable products: we have not yet seen success. It's not helping engineering folks, it's not helping product folks. It's creating a ton of questionable output and hasn't resulted in real ROI, and it's not capable of accurately answering deep domain questions without hallucinations or assuming what works in one jurisdiction works in all.

I've seen success in many other areas, but not this domain - and, importantly, the regulatory environment in which title insurance operates is incredibly complex and strict, meaning you can't just YOLO LLM output into production (as much as we'd love to try so we can learn at a faster clip).

And the kicker: we've found the way for us to build the best products is still going out into the field, sitting with escrow and title folks, watching them work, asking them questions, and designing for the real world, the regulatory nuances, the local client nuances, etc. You can't get that from an LLM.

Agree on this one. As a Civil engineer, I can smell which software ( or some part of) was developed by computer engineers without much understating of the "domain". The worst offenders are software needing multi-domain expertise in the first place. Crude Ex. Payroll (Finance) and Leaves (HR) are 2 seperate domain, and they need to account for each other.

This is such a sane take. It is THE reality we have been always ignoring.

Writing software has never been difficult. It is the domain that has been the issue. Always.

Writing software has never been difficult.

That's not true at all, sure CRUD might not have been that difficult, but absolutely there is extremely complicated software out there that is really difficult to write in a performant and correct manner.

Yes. Audio, video encoders, decoders etc, 3D modeling, rendering etc.

That too is "domain" even it feels like it is NOT. Domain of signal processing, Euclidian spaces, information theory and what not. Thar too is all "domain" and that "domain" part is difficult to write.

Then what do you mean by pure software? I think there's essentially zero domain-free software.

It is kind of funny though how all this hand wringing on performance, graphics, quality quality quality, has just resulted in basically same stuff as what I was doing with my computer in 2000 but with enormous resource use in comparison. Still playing games, still same old discussion forums/social media/whatever on the internet, same email and office suite, same chat, same media players, same everything. I can't even see the difference between 1080p and 4k from a couch, and people are trying to sell me 8k to watch the same stuff.

It just does not matter. The ideas matter. Novel functionality matters. But that isn't what any of that is. Same old. And the effort spent, the resources, the energy. All for more polygons on Lara Croft.

I mostly agree with you, but you couldn't have have meaningful live videochat between continents in 2000.

CU-SeeMe worked pretty well in 1995 if you had access to a half decent Internet connection, which admittedly most people didn’t.

For well funded organisations, ISDN video conferencing facilities were reasonably common.

Verizon in NYC was trying to make ISDN happen in the home in the mid 90's. I had it. The hard part was getting an ISP that supported SLIP.

In Australia ISDN was available pretty much everywhere to any residential customer who wanted to pay for it, but it was not particularly popular. It was widely used by businesses, however.

The main reason was that the line rental was significantly higher, POTS lines had untimed flat rate local calls, whereas ISDN didn’t, and ISPs charged more for ISDN plans.

Towards the end of the 90s that changed for voice calls, and so a fair number of folks who couldn’t get ADSL for one reason or another got DoV (Data over Voice) Internet services. This is where you make a single channel ISDN “voice” call, and then use it for 64Kbps data. Most ISPs supported it on ordinary dialup plans.

This gave you significantly better speed, and much improved latency compared with what could realistically be achieved with V.90.

all this hand wringing on performance, graphics, quality quality quality, has just resulted in basically same stuff as what I was doing with my computer in 2000 but with enormous resource use in compariso

Mordern GPUs are streaming multiprocessors. Complaining that GPUs use a ton of resources is like complaining that a firehose uses a ton of water. Maximum data throughput is the point!

But that isn't what any of that is. Same old. And the effort spent, the resources, the energy. All for more polygons on Lara Croft

There are MANY novel games being released every year. It's up to you to find them.

I'm willing to bet all those novel games would have still been great games if they took their underlying mechanics and were making them in early 2000s with that era graphics. Ray tracing isn't a game mechanic. Neither is hair physics.

I disagree because we're buying up companies and training models, creating skills and agentic workflows on individual domain expert's 30 years of notes and prior projects

The only moat is that there is so much more work for domain experts since they and many of the bureaucratic processes in between aren't the bottleneck anymore

I think it's important to be clear on what's really happening. Companies were accomplishing 5% of their annual plans, and now they're taking a realistic swing at all 100% to likely reach 20-25%. It's a crazy amount of work, for the same specialists and more human workers.

But that’s not true though. You still have to convince humans. You still have to deal with what people in power feel (clients, leads,etc) This still adds wall time. I saw 0 serious analysis confirming 5x productivity gains. In the coding part? Maybe, and that’s not even certain. But pure coding is only one order of making software, or solving problems with software

LLMs are the best domain experts, but the curse is that they know too much.

so it takes a domain expert to remove unnecessary things, similar to how stone carvers create by removing material, not adding

I feel like this aspect has been discussed on HN many times. The thing that resonates with me strongly is that there’s rarely a clear or fixed set of requirements to begin with - at least from my work experiences. Then, domain expertise helps with being able to proactively call out when they are missing and support in defining them. Still I am of the view that with enough context AI could also replace the best engineers with the best domain expertise.

Not just domain expertise. The hard part has always been marketing, distribution, risk appetite, motivation, grit, and patience.

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.

Such a good example of this I encountered recently:

I was on a fishing trip. I asked the charter if he’d want to check out a free app I work on (https://oceanconnect.ca) in case it might be useful for his work.

I don’t know how people on the ocean use ocean data. I don’t really know what they want to know, or why. I wasn’t totally prepared for the incredible onslaught of questions and information pertaining to how people use the data or what we can do with the data, and it was so cool and exciting to get that perspective.

It was a good reminder that models are not the same as the systems they abstract, and knowledge to develop them has almost nothing to do with using them. This guy was a wealth of knowledge about how they use weather data on the water. In a sense, he knows more about the data than I do (even if he doesn’t realize it, or doesn’t understand it in its digital representation), and would be far better equipped to make a useful application for people like him if he could program.

I found myself thinking people like him could actually do amazing stuff with LLMs if they sat down and got their ideas out on a screen. I’d really like to interview people on the water daily some day to refine the product if we ever have the funding. That domain knowledge is highly, highly specialized and people know things you’d never guess after living in a complex domain for decades.

> I found myself thinking people like him could actually do amazing stuff with LLMs if they sat down and got their ideas out on a screen.

They can, and they are. You just don’t hear about it on places like HN because those people are not on this website. Which is why some people here make smug statements like “if LLMs are so good at programming how come we haven’t seen any useful apps made with LLMs???”

You’re right. I have a friend who works in landscape architecture and he’s getting up to really cool things involving parametric modelling tools. Stuff he couldn’t easily do with off-the-shelf software is now attainable and he’s going wild with it. You’ll never hear about it here (though it totally belongs here)

I’ve posted about it a lot, it’s posted all the time. It’s pretty much the main topic

The issue isn’t that it’s not happening, it’s that people on HN have their identities tied to typing code and can’t deal with the fact that amateurs are trying to compete

The software generalist described in this post has domain expertise as well. In software.

If you’re a great generalist software engineer today, you aren’t jumping to some random domain to escape AI. Software is your domain. You’re sticking with it as it expands and transforms.

Exactly, plus you now have a new superpower with AI — the ability to dig into and ramp up expertise in mostly any domain. I’d say the article gets it backwards.

Expertise is largely tacit knowledge, reading AI slop isn't expertise.

My friend is an electrical engineer and just passed a FIDE chess rating of 2000. Has played for 30 years, started the chess club in high school. Knows a little programming from the stuff he had to do with microcontrollers in college.

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?

I think a charitable interpretation is that from the perspective of AI, some domains are shallow (like chess), and some are deep (you can fill in the blank here).

What would fill in the blank be? Because this was actually kind of a test for me to address the question of "does AI just amplify domain knowledge?" In this case, it seems it didn't.

For the purposes of chess the domain knowledge is the game rules. And from this pov there is really not much to describe, knowing en-passant exists is the peak of domain knowledge.

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.

I don't know how you can say application and experience isn't domain knowledge. If it isn't, I have no idea wtf we are talking about and I'll have to accuse you of moving goalposts.

You use websites a lot.

Should AI make you really good at frontend development?

Infinitely better than I was before it, yes. If not, what's the point?

what does actually playing chess have to do with writing an efficient game tree search algorithm beyond a few simple principles? You challenged him to a programming contest and won, as the vastly more experienced programmer. Even though he could use AI, your domain knowledge here proved to be the deciding factor.

I had never tried to make a chess bot before though, we both started at the same spot. There are obvious things you can search for to make one. We both had the same information there. The domain was chess, and his expertise didn't help him win. If you are a chef, shouldn't you be able to make better recipes with AI? If you are a fitness trainer, better routines? Etc? Or is AI only for programmers?

I've studied how pre-NNUE stockfish worked and the principles of static position evaluation are accessible to a 500 rated player. The rest is writing an efficient search algorithm, which is purely an endeavor in computer science, not chess playing. So your expertise in programming gave you the leg up here, and predictably your opponents experience in chess doesn't help. Your point only serves to bolster TFA's argument.

You can say that about any domain. I'm done with this. What I'm hearing from people is that AI is only for programmers and is useless for everyone else. And it honestly seems to be that way.

Writing software for which a full spec is available before you begin — in this case the rules of chess — was an easy problem even before AI.

There's no chess spec, it's not "solved" like it's just a matter of implementation. Chess bot programming wouldn't be a thing otherwise. I think it's really quite funny that you think this super complicated game is just some trivial programming problem. Try it.

I think this might be one of the worse examples of the dynamic, for the reasons already mentioned by others (programming a chess bot is really more of a programming exercise than a chess exercise), but it’s food for thought, so thanks for posting it. Some IRL domains are definitely more chess-y than others.

I recently reviewed an app built mostly with vibe coding. The owner said it was almost ready to launch and just needed a quick check.

After looking through it, the database design was a mess. Some features worked, some didn’t. I explained the missing pieces and why things were breaking. Like OP said, he’s the domain expert.

I used billions of tokens last month alone. The tools are getting better fast. But giving AI to a domain expert doesn’t mean you no longer need software engineers.

A domain expert can use AI to build software. And a software engineer can use AI to learn about the domain. Both bring different expertise to the table.

Where I am headed, I think, is to basically be a platform engineer. The job is to create the guardrails, validation, prompt library, and both agent and manual reviews; that keeps the domain experts safe when they start using coding agents.

It's a little bit like being T2/T3 customer support [or support engineer], but internal. You're there to catch the dangerous spots, the weird edge cases, and to make sure that everything is set up correctly, rather than to solve 100% of the routine problems yourself.

There's also plenty of room for cross-cutting-concerns, of course

Can you elaborate more on this type of role? Stack? Etc.

Domain expertise combined with a QA mindset could replace SWE, but consistent QA mindset is rare

Personally my ability to understand atrophies / is reduced when compared to writing code ‘myself’ rather than fully being a reviewer.

Probably similar to hand writing notes (while digesting + synthesizing and not just being a scribe) vs reading notes somebody else took.

I agree that a consistent QA mindset is rare, but I'm not sure even if present if it's enough to replace an SDE.

I very recently looked at the codebase of a vibe-coded app made by someone with domain expertise but no software dev experience.

It was very clear to me that he had described it from his POV to an AI, and the AI had implemented features in a manner that technically worked, but made future maintenance or expansion extremely tricky, which is why he was now looking for a dev.

For example, in his data schema, for every item on a menu, instead of simply having an array property like so for ingredients:

    items["latte"]["ingredients"] = ["water", "milk", "sugar", ...]

He had individual flags for every item for every possible ingredient it could have or not have:

    items["latte"]["has_milk"] = true
    items["latte"]["has_nutmeg"] = false
    items["latte"]["has_cinnamon"] = false
    items["latte"]["has_sugar"] = true
    ...

This technically worked and passed tests from his POV at an MVP level. But added a lot of complications when actually trying to build more features or when a new menu item had ingredients the founder hadn't thought to include in the schema beforehand.

I totally get how he ended up where he did though. While describing it to the AI, he probably said something like "store info on each menu item's ingredients, they might have milk or coffee or sugar", and the AI created individual flags for them and he didn't think to question it, because he didn't know what's "right" or "wrong", but then as he kept building the AI stuck with keeping individual flags instead of swapping it out with an array mechanism, and he couldn't have known the correct way to implement it.

Only a dev with experience would know how to describe the system to an AI model to get an output that works well, and how to assess the quality of its output beyond what can be assessed through the basic UI. This wasn't a QA failure, it was a design failure.

I disagree. At some point of complexity, building it yourself is faster, better and (as we're finding out) cheaper. And more fun, although that varies person to person.

Wrestling with a code generator also creates a sunk cost fallacy where progress grinds to a halt but you still try and use the tools to fix the problems the tools created. Or you go in and fix things yourself, in a codebase you don't truly understand. A single developer can recreate the contextual nightmare miasma of a large corporation all by themselves.

There's also an emerging market consideration: MVP are easy to build so time to market is no longer hard to achieve. It's not a differentiator.

X was built in 3 days but is slow and riddled with bugs and security errors. There are also A, B, C, D and E which are effectively the same thing built just as fast.

Z was built over six months and is rock solid and performant.

Who wins the market share?

Who's got better marketing? Is it even a product that customers care about rock solid and performant? Which ones cheaper and has the least friction to getting started? Which one's CEO golfs with your company's CEO?

Time and time again, the market proves worse is better, from the format wars of the 80's and 90's, to Microsoft Windows still being dominant (and oh yeah, Teams). Sometimes quality does win, but if being built in 3 days means they can make a profit charging 1/100th the price of Z, I wouldn't count the cheap ones out of the game just because Z is better.

I used billions of tokens last month alone.

I use Claude Code (Opus 4.6 at max effort) all day long, and I genuinely don't understand how this is possible. Is that usage paying off?

This is very likely due to my lack of understanding, but... how?

Long codex sessions lead to a lot of cached token hits, esp when you resume them after a few hours.

I personally don't count cached hits as $used... Neither in my harnesses, nor in the LLM-enabled apps I create. A cached token cannot be counted 1:1 as to a non-cached token, that would be silly.

Wait... when some Claude 5x/20x users say they are getting "$2000 of tokens for $100," does the 2k value include cached tokens, counted at the same $/token either way?

We cannot be this dumb as a community, can we? I must be wrong/misunderstanding..

Vibe coded a simple game (10,000 tokens of source code) with two popular coding agents. (Once each, to compare.)

One spent 200,000 tokens, to produce 10,000.

The other spent 1.9 million.

It could have been a single LLM call (10k tokens). lmao

(I note that the latter was designed by a company whose main source of revenue is token spend...)

What about the other 998 million tokens?

Don’t forget context. Basically I have 2 billion input and 1 million output. Every prompt you do, sends back the whole thing again and again. Let’s say you have 500k context used, you send 10 messages is 5 million. 100 messages 50 million. Use 5 threats is 250 million.

In the past, an engineer who deeply understood the internals of a DB and how memory management worked in Java would be indispensable.

Now these skills don't matter as much because LLM's/Cloud/Java abstract out these problems.

What makes domain expertise a different category itself that lends it to be not automated out by LLM? Example: Why can't I go to into an agri-startup and become better than anyone else by querying an LLM even when I have no domain expertise? Much the same way I beat the dev who was good at DB internals?

How much pontificating needs to be done before people acknowledge nobody has any idea what to do with AI on an individual level?

First being good developer and learning how to use AI was sufficient, next it was being able to design architecture, then it was “taste” that made all the difference and now being an expert in the domain is the only thing that matters really.

Until AI is basically in a stable, predictable, state of improvement or stagnation, these takes will continue to be pointless and most likely completely wrong.

Haven’t you heard? If you don’t adapt now you’ll be left behind, never to be able to work again! Copilot? That’s so last year. Agentic engineering? You’re already late!

Overall I agree with this, though I do think that there will be a trend to hoard/keep-secret domain knowledge by professions. Like plumbers will try and make it a trade-secret or protected intellectual property how to change a pipe fitting.

For basic residential plumbing work the moat is not knowledge. There are already books and YouTube videos that will teach you everything you need to know. Professional plumbers can't stop that. The real moat is that most people don't have time, don't want to buy tools, and don't want to get shit on their hands.

For new construction and commercial work the moat is a contractor's license. They don't allow LLMs to take the licensing exam yet.

LLMs are an additional tool to add to your arsenal. They are not omnipotent and need care, just like any other tool.

My best effort, so far, at an analogy is a modern drill driver compared to a screw driver/brace and bit/etc:

You can get some remarkable results in a very short time compared to the "old school" gear.

You can get some "amazing" anecdotes eg "I screwed down an entire floor at 16" x 1" c/c within an hour instead of an entire day and I took loads of fag breaks" (I could have used a nail gun instead in half the time but I'll never raise that floor easily in the future, and probably done at twice the cost)

I have several on prem LLMs and access to the rest and I'm pretty sure I'll be extending my analogy to ... brand, eventually.

What I do not expect to be doing is looking for a new job. A drill driver is not a carpenter/site labourer/useful without a person!

But a modern drill absolutely 100% removes the need for a brace and bit. An LLM doesn't replace any existing tools.

From what I've heard for many devs it replaced an IDE... I still use one myself, but I've a lot of people don't anymore.

Basically IDE free since May 2025. I actually reinstalled vscode when setting up a new machine and I think I've launched it twice?

cc -> local automated testing -> github -> PR -> heavy integration tests -> review (github ui, +/-) -> manual test locally -> merge -> deploy -> manual test remotely -> synthetic user testing -> repeat

Do you not need to use the debugger sometimes? Or can cc debug by itself

I have not used a debugger in anger in perhaps a decade. I write tests, and if that's not enough, I write more tests.

Tests stick around and prevent future problems, whereas the debugger only shows me something once.

But tests show you if a bug is happening, they don’t help you understand the underlying cause of the bug. In a decade, you haven’t hit a compiler codegen issue, a silicon erratum, a race condition, or anything that required actually spending effort understanding the causal path?

But what about navigating the code by the call stack? I didn't know that GitHub has a way to do that. Or maybe I'm probably coming across as being dumb enough to be talking about still trying to have a mental model of what calls what.

I write software that makes money and AI helps me write software that makes more money.

Remember the OOP Hype 20 years ago? I'm still cleaning shit up from then in our codebase when everyone used patterns after skimming through the GoF book without even knowing why .... My prediction is in 20 years I will clean up the shit that was co-authored by Claude ...

https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...

OOP and GoF are not the same thing - conflating the two has been the biggest mistake everyone has made (detractors and proponents alike)

And there's nothing "wrong" with the GoF Patterns per-se. The issue was always people applying them blindly without understanding why (or more to the point, "if") they were needed. Once writing code filled with patterns became "the thing you do"... all bets were off. :-(

I remember putting stuff like this on my resume "developed X using visitor pattern" . ppl would ask "what is your favourite design pattern" in interviews. lmao.

Lol the worst pattern

Strangler fig is one of the best, with one of the worst names

So far AI has been a (genuinely) massive improvement for...

Search

It's reading my requests more clearly than (for example) Google's search input ever did, and it's got (some) understanding of how close the result (or fragments of results) are to what I want.

I can ask it about things I know about, and it can answer with strategies I hadn't thought of.

HOWEVER - I still need to understand the results AND AI can overreach - it can say (figuratively) "Oh you are searching for Event handling, therefore I will write a orchestration saga" - which, if I am not across, can get us both in trouble.

Further, we KNOW that AI has no (real) understanding of the responses - it's just token adjacency - and it fails basic logic tests

Current AI is just awesome natural language processing, but it's still got a ways to go to where I would say "It can replace people"

Edit: LLMs demonstrate (almost perfectly) the difference between correlation and causality. LLMs identify correlative patterns, but the job still needs (us) to make the causative judgments.

It's reading my requests more clearly than (for example) Google's search input ever did

I see this take a lot and it puzzles me.

While I think LLMs provide some advantages over traditional search in some modestly nontrivial contexts, they tend to be inferior to traditional search at its peak. I attribute this attitude to two things: the broad progressive enshittification and productization of search, and the fact that (re)search is a skill that most people tend to be bad at. Without massaging, LLMs spit out the most utterly braindead boneheaded queries, which are fine in cases where the problem is very well understood with minimum uncertainty or critical nuance. If your problem has either, God help you. But perhaps those queries are at least as good as the average human generated query

I think that the issue here is that the definition of search/results has changed (in my mind at least they were always - what knowledge are you looking for, followed by, here are the results that carry that knowledge OR point in the right direction, but I recognise that other people will hold more strict definitions)

AI has changed how I find and synthesise information in ways Google never managed - we've always had the problem with Google that we couldn't express exactly what we were looking for - that much I think we can both agree has changed dramatically for the better with LLMs

Edit: I have always held that searching for an answer (whether it be internet or human) has always been about asking the right person, the right question, at the right time.

LLMs most certainly improve that - I don't need to know the exact technical term I am looking to solve in order to get the results I want (eg. I can ask how to "stop (a) function from running too many times" instead of the industry terms "throttling" or "debouncing")

Edit: I have always held that searching for an answer (whether it be internet or human) has always been about asking the right person, the right question, at the right time.

At the peak of search they're describing, asking a question was how you'd get subpar results. The best way to search was for things you expected to be in the results - like, for a simplistic example, you wouldn't search for "how do I...", you'd search for something like "How to..."

Until AI is basically in a stable, predictable, state of improvement or stagnation, these takes will continue to be pointless and most likely completely wrong.

Little thing to keep in mind about AI: a technology is only called AI while it doesn’t work yet. Once it works reliable, we give it a proper name and something else becomes AI.

nobody has any idea what to do with AI on an individual level?

I appreciate the frustration, but some of us are actually successfully using these tools.

An idea that's beginning to solidify for me is that AI tools make software development harder.

It's harder because they dramatically raise the bar for what's possible to do. An individual developer can take on significantly more challenging projects now, because the ultimate constraint has always been time and AI can help you get more done in the time available.

But the stuff you can get done with that time is a whole lot harder. You have to understand lots more things, and get radically outside your pre-AI comfort zone.

It used to be acceptable to spend several days refactoring a codebase, or figuring out how to ship a small feature because it's in a part of the system you hadn't worked in before or involved learning a new library in order to build it.

Coding agents mean you can climb those curves a whole lot faster, but you still need to climb them - and the volume of information coming your way is much higher.

If you're worried about non-technical vibe coders taking your job, the correct response is to be much better at building software than those vibe coders. That means you need more skill, more ambition, and more experience. It's hard!

Not really. The primary stopper was never time or effort. It was need (and wisdom). If a project was important enough, you’d do it. If it’s not, it falls on the wayside.

Now with LLM tools, what you got is a slew of projects their creators aren’t even interested in. It’s theater.

There's just no way this can be true. Every project I've committed to has been a bet made with incomplete information. Sometimes it pans out, sometimes it doesn't. Every time I've made one of those bets, I've had to shoulder the opportunity cost of 2-3 other 1/8th-finished but promising projects I could have driven to completion instead. Not having that opportunity cost anymore wildly changes the dynamics of what I build.

This weekend I'm playing with a SwiftUI MusicKit player (everything I'm doing lately has been Swift/SwiftUI, itself a radical change from just a couple months ago when everything was a TUI, and then a few months back from that and all the way back to 1993, when everything was a CLI) with a Responses API hookup that turns the player into an agent, with tool calls to let the model see what I've been playing. "Keep a continuous queue of music playing while I'm working in the wood shop".

Worked a treat. I'm genuinely interested in where I can take this. I have a real problem, one that's been annoying me since ~2000, which is that I "own" a lot of music but find myself stuck in an epicycle of the same 200 songs. Problem solved-ish. I never, ever, in a million years, would have built anything like this before.

It's really hard to sell me on the idea that nothing profound has changed here in terms of the projects we now pick up. Go build an operating system. I'm serious! Claude will practically one-shot it. Mine has smoltcp hooked up to a Rust virtio-net driver Claude pulled out of its butt.

developers now are expected to randomly jump around projects and ship without friction. For employers it means they can move us around like pawns. Lot of companies have not reorged themselves to this new type of workforce thats much more malleable.

it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.

Working in silos like this has always been an anti pattern though. You end up being employed for 10 years but only have 1 year of actual development experience. Just turning-the-crank and going home was always risky because one day you get laid off and realize you’re 10 years behind the competition.

So what enables job security now?

Being a really good engineer - the kind of engineer you can assign a feature to and they promptly turn around a robust, maintainable, secure and well documented implementation.

hey... claudex helps me being that.

So does your IDE, your choice of programming language, your OS even — but does it define you/make you a good software engineer?

No, but who said that ?

Let them attempt to use ai to build business critical systems and when they waste tens amd hundreds of millions they can rehire master builders who know what they're doing

They will attempt and then soon enough they will be succeeding, and the master builders will have all retired, and that's the point that humans become dependent upon AI's. I aim to live a couple more decades and I sadly expect to see it play out this way.

developers now are expected to randomly jump around projects and ship without friction

This describes the expectation my managers had of me at every software job I've had, and I've been doing this for a decade and a half

It's definitely not a new thing since LLMs came around, if that is what you were implying

That's a roundabout way of saying it makes software development easier. Perhaps even a 180.

But yes - once it's that easy you have to step up your ambitions.

Maybe it makes software development easier, but a career as a professional software engineer harder.

I hope that after a short period of delusional expectations and layoffs from employers we're at least left with a more consistently competent set of professionals in our industry. Some people have imposter syndrome. Others are actually just imposters.

Some people have imposter syndrome. Others are actually just imposters.

I'm sorry to say, but AI coding assistants paved the way to professional imposters whose only skill is prompting a model to do something. I already had the displeasure of working with a software engineer who not only introduced a bunch of regressions that by mindlessly vibe-coding things against the requirements but also complained that not having credits to use the most expensive frontier models was, and I quote, "stifling my creativity".

You will never beat the vibe coders.

The vibe coders have a key advantage you don’t: they don’t give a fuck.

They blow through a task and move onto the next one. Management sees this as progress, and the vibe coders are rewarded.

When shit breaks later on down the line, and fires have to be put out and things rewritten, the vibe coders do NOT get the blame. They do NOT get punished. Most engineering teams operate on a blameless culture. If code was approved for production, then it should have been good enough. Vibe coders will keep on doing what they do, and skilled experts will be left cleaning up their messes.

For anyone who actually cares, it’s over. You are not steering development anymore.

Who approved the vibe coders’ PRs?

That might be true in the short-term, but I'd be very surprised to see that hold for the long-term.

We've had plenty of technology trends in the past that have promised faster development but has later turned out to have problems. Organizations that stick around learn lessons about what works and what doesn't.

If in a year's time organizations aren't feeling severe downsides from all of the unreviewed vibe-coded junk they put into production then maybe the vibe-coders were right. I'll believe that when I see it.

If the vibe coders are right I would give at least 90% of the credit to all the well made libraries, rules, and best practices that developers have built up over the decades. That’s what is embedded into LLMs and what might be the saving grace of slop code bases in the future.

(...) rules, and best practices that developers have built up over the decades.

It seems you are not understanding that the reason all these "rules, best practices" had to be created in the first place was the fact that your average old times developer was churning out shit code and weaving spaghetti just as hard as today's vibecoders.

Those "rules, best practices" spawned from the same evolutionary pressure as today's instruction files, skills, custom agents, etc.

Why do you think one of the first AI features rolled out by GitHub was the automatic code reviewer?

You guys are talking as if everyone working on software before 2020 was this immaculate developer with pristine sense of architecture and style. No, they were not.

All that stuff you mentioned is derived from a core set of principles established by decades of software best practices applied to a new means of generating code. Like quite literally those instruction files/skills essentially just reiterate the practices themselves.

To your last paragraph, I never say that nor do I imply it. I find that as a pretty disingenuous interpretation of what I said actually. The practices I mentioned were derived from hard learned lessons and designed as a means of mitigating the human tendency to write bad code.

From that perspective, development has always been harder since I started. I left college with a copy of K&R and remembering courses that applied to real life immediately, because data structures and such were just what we had. In my first job, I ended up writing a code generator to help serialize a large number of data structures, straight from a compiler design class.. which right now you don't need to know a thing about, because serialization and languages with introspection are everywhere. The knowledge you need to be a professional engineer just kept going up through the last 30 years, while most of the basics became far less relevant, because the libraries just did it.

AI raises the bar again, as its probably at least as good as me, if not better, at anything I learned in college. I've spent years living off of random trivia from the last 30 years, as I saw computing grow with me. How do you know this?! Because everything built on top of it didn't exist when I was your age, so I had to learn it! But well, nowadays the AI is better at that trivia too.

The world moves, we do what we can with what we kno. It's not just programming, but what innovation and automation has done to the vast majority of things humans have done to be productive for each other since humans are people. We'll have to cope, like the guy that bred oxes to pull the plows.

I worry this is looking at where the ball is now instead of where it's going. The recent disproof of an Erdos conjecture should put to rest the idea that LLMs will reach a skill ceiling before they reach superintelligence.

I believe we are headed for a world of superintelligent AI where LLMs are much better at logical thinking than humans, the same way that chess engines are much better at chess than humans.

In that world there's really nothing humans can offer in terms of logical thinking other than their humanity itself. An 8 year old with Stockfish can beat Magnus Carlsen, and an 8 year old with Codex (and daddy's credit card) will be able to beat me at software engineering.

I don't buy that at all.

It doesn't matter how great the LLMs get, the act of creating software using them will still require a great deal of skill.

Most people just don't think in terms of software.

Try asking a non-developer in your life what their dream software would be for their work, or their hobby. If they don't have what Nilay Patel calls "software brain" I'd be surprised if they came up with something actionable.

(For more on software brain see "THE PEOPLE DO NOT YEARN FOR AUTOMATION", which makes the point I"m making here but much, much better: https://www.theverge.com/podcast/917029/software-brain-ai-ba...)

You could give a non-developer the smartest LLM in the world and they wouldn't be able to create GitHub with it, because creating GitHub requires an enormous amount of understanding of what software developers need from a cloud source control tool.

Sure, you can argue that the LLM "knows" what GitHub needs already and can guide their human-user to that, but why would a human-user who doesn't understand the domain ask an LLM to do that in the first place?

Try asking a non-developer in your life what their dream software would be for their work, or their hobby. If they don't have what Nilay Patel calls "software brain" I'd be surprised if they came up with something actionable.

I've posted this in numerous comments because I think it bears repeating: there are tech-savvy non-developers who are actually building and shipping stuff with AI. I personally know a few who have been successful in acquiring initial customers.

You can say "but their apps won't scale", "their apps aren't secure", etc. and you might be right but these criticisms ignore the fact that most human-built software suffers from issues around scalability, security, etc. What AI in the hands of a relatively tech-savvy person is capable of is building functional, usable applications that are pretty decent compared to what you might get if you paid an experienced contractor tens of thousands of dollars to build.

A whole generation of young people has grown up with the internet, smartphones, etc. They might not be trained software engineers or have a "software brain" but in many cases they probably have a better intuitive sense for digital product design than a 30 or 40-something engineer who has been staring at an IDE for the past decade(s).

there are tech-savvy non-developers who are actually building and shipping stuff with AI

I absolutely believe that. I think those are people with "software brain" who are on their way to becoming real developers.

By the point they can write apps that are secure and scale... they'll have learned enough about software development to be employable as software developers. They'll be part of a new breed of developer who never memorized the syntax of a programming language, but they'll still be at the starting point of learning a HUGE volume of other stuff that's necessary to build good software.

If we want to stay employed, we need to be notably better at building software than they are.

I absolutely believe that. I think those are people with "software brain" who are on their way to becoming real developers.

In my opinion, this is a software developer-centric way of thinking that reminds me of the saying, "if all you have is a hammer, everything is a nail."

Here's an alternative perspective:

For billions of people, technology products are an integral part of daily life. As a result, lots of people have an interest in building technology products, particularly software. Thanks to AI, you no longer need to be a "real developer" to build software. You can learn enough to build things that are commercially viable without seeking to be employed as a developer.

If we want to stay employed, we need to be notably better at building software than they are.

While I don't believe that the market for developers will shrink to 0, unfortunately, I think this type of comment reflects the fear, existential angst and denial that has overtaken many people in this industry.

The reality is that developers are no different than all the displaced workers who came before them. One day you had a job that seemed secure and capable of providing for a comfortable life and the next you were facing the prospect of diminished wages and unemployment because the world simply needs fewer people with your skills and there's no way around the secular trend.

The sad irony is that when software was eating the world and new CompSci grads could take their pick of $150,000+ job offers before ever writing a line of production code, a lot of people in the industry had a smug "tough luck" attitude towards all the workers being displaced by the tech boom. Now it's their turn.

Maybe the tools are going to get to a point where this isn't true but today even with Claude Code at whatever at hand you're going to have to learn enough about software to basically be a developer in the traditional sense to deliver a multi-tenant application that has to deal with high TPS or whatever. At least at present you're positing there's no need for carpenters because the home gamer can knock together a table or birdhouse at home.

Nevermind syntax, what's a variable? function? class? What's the difference between int/float/boolean string? Nevermind more advanced concepts like O(1) vs O(n). But when the vibe coder just needs to prompt "the page loads really slowly. plz fix" and the LLM can go in, add an index to the right SQL table, add a limit and pagination, so what if I can tell you the difference between PostgreSQL's dialect of SQL vs MySQL, and what the difference is in row types supported. I can describe what happens when you type Google.com into your webbrowser to an inane level of detail off the top of my head, but when the LLM can do an even more through version, I mean, I can pat myself on the back and be smug that I know most of that innately, but what is it really worth?

About a decade back, we, as an industry were collectively learning how to make apps webscale, and oh the blog posts about not using a database as a queue. But the LLMs have ingested all of them. I've only read the ones I came across, and of course my professional experience being part of teams implementing that at various companies. So I've got that going for me, but when the Vibe-platform-dev just has to tell the LLM "hey, when the user hits the send message button, it's slow. /goal make messages fast", and the LLM grinds for hours overnight switching the entire system over to a pub sub event driven architecture and the vibe-platform-dev doesn't even know what pubsub stands for or that they're using one unless they go back and read the transcript. I don't think there's as much of a domain expertise moat for as long as we're hoping.

It only takes two or three unreviewed prompts like "the page loads slow, plz fix" for you to end up with a tangled mess that even the agents can't productively work with.

Take a look at the Reddit forums for vibe-coders - now that a bunch of them have been hacking on things for 3+ months there's a growing awareness there that you hit a wall. Here's the first post I found from just searching "reddit vibe coding wall", it's a great illustration of the genre: https://www.reddit.com/r/vibecoding/comments/1sabdw3/anyone_...

Software development is really, really hard. Coding agents can get you a surprisingly long way, but if you want to build real software for real people you quickly find that you DO need that domain expertise.

The agents may type all of the code for you now, but you need a huge amount of skill to clearly tell them what to do, confidently decide what to do next and credibly present software that works for other people to use.

Im not understanding why the discounting of your prior knowledge somehow slides over to a benefit for the non-technical vibe coder?

wouldnt you still be in a better position when prompting “site slow, make fast”?

I agree, and I want to add that 'better' doesn't necessarily mean 'creates more robust, elegant, resilient software'. Better means from a business perspective. If we (I'm one of the people you're discussing) end up cheaper or more fungible, for example, we still might be worth hiring from a business perspective even if the code we create is shit.

I've also seen an assumption that you've made here that I think is worth drawing attention to and questioning: that the tech-savvy non-developers are starting from zero or near zero when it comes to programming and software development. Right now, that's probably mostly true, but I'm not sure that will continue to be the case. I'm not a developer (depending on how fuzzy we want the boundaries around the idea to be, anyway). I do understand the building blocks of programming languages (e.g. I can answer all the questions fragmede posed in a sister comment), the trade-offs between rolling your own and using existing libraries, the need to evaluate tools, frameworks, and languages to determine which is best for your use case, why version control matters, why access rights matter, why backups and a test environment are necessary, why it matters to write code another human can read, etc.

Do I understand as much as an active working developer? Absolutely not and I'd never claim to, but I'm far from starting at zero.

The reason for this is that I was raised by programmers. There are far, far more programmers and general tech nerds now than there were in 1988 (when I was born). Which means that in 10-20 years, there are going to be a lot more children, grandchildren, nieces, nephews, and so on of developers, and a lot of them are not going to be starting at zero. For pretty much of all computing history, there's been a substantial opportunity cost to developing a deep understanding of coding and software development: either a person has to be so into the domain that they devote a lot of their waking hours to it (usually in adolescence or young adulthood, when that trade off closes the most doors and makes developing certain other time intensive skills difficult), or they have to obtain a CS degree, which means not getting a different kind of degree and often incurring significant front-loaded financial costs. The opportunity cost for people born into programming or tech families is much lower. You can start younger and spread out the hours needed to learn across a greater amount of years, you can acquire knowledge in less time-intensive ways and while practicing other skills (e.g. my cousins also have 'software brain' and we could all hang out and develop those skills while also developing in person social skills), and you have a built in network of experienced people who want to help you + that can give you extremely individualized, personalized attention.

If what you suggest comes to pass, I think that one of the greatest threats to SDE as a career is going to be your own children and grandchildren.

there are tech-savvy non-developers who are actually building and shipping stuff with AI. I personally know a few who have been successful in acquiring initial customers.

It'll shake your world, but tech-savvy non-developers were building and shipping long before AI.

they probably have a better intuitive sense for digital product design than a 30 or 40-something engineer who has been staring at an IDE for the past decade(s).

Because developers only stare at IDE 24/7, and never interact with anyone besides mother who brings tendies to their basement? What am I even reading?

It'll shake your world, but tech-savvy non-developers were building and shipping long before AI.

They weren't building and shipping by themselves though. They were hiring people to do the work.

AI has made it possible for people with motivation and time to do what was previously only possible with motivation, time and money.

Because developers only stare at IDE 24/7, and never interact with anyone besides mother who brings tendies to their basement? What am I even reading?

Why is so hard to acknowledge the fact that many of the people who are good at developing aren't as good at coming up with ideas for digital products and building businesses on them?

They weren't building and shipping by themselves though.

Yes they did, all the time. You just need to get out of your tech bubble.

AI has made it possible for people with motivation and time to do what was previously only possible with motivation, time and money.

Nonsense. AI simplified it, but programming was always accessible to the masses. They might not have shipped full blown SaaS products, but people have been programming with Excel, Access, Python, JS forever.

Why is so hard to acknowledge the fact that many of the people who are good at developing aren't as good at coming up with ideas for digital products and building businesses on them?

Because it's a complete straw man detached from reality.

Chess and proofs only work as comparisons to the extent that you can find parts of your job that share their key property: A solution is sought to a problem that can be stated with relatively little information.

What prompt would someone have used to get a superhuman coding agent to output the Linux kernel or GTA5?

Before you accuse me of moving the goalposts, that's not my point: The examples are there to help think about what humans would still need to do to build complex projects even if the coding itself was perfectly reliable.

Both the Linux kernel and GTA5 contain a large amount of incompressible information; humans thought long and hard about how to design them, i.e. about what that thing they were building was even supposed to be.

If you're worried about non-technical vibe coders taking your job, the correct response is to be much better at building software than those vibe coders. That means you need more skill, more ambition, and more experience. It's hard!

This is a false fear. The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shrinking.

Also, even if the premise behind the SaaSpocalypse is naive and oversimplified (companies aren't going to replace all their SaaSes with internally vibe-coded replacements), it looks reasonable that net-net AI will have a negative impact on the value of software.

The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shrinking.

That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.

It’s also a poor take in general, buying very much into the narrative propagated primarily by OpenAI and, especially, Anthropic, who nonetheless continue to hire large numbers of SWEs while paying double the market rate.

That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.

Source?

https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE

And it's probably worse than it looks because phantom job postings are a real thing.

...who nonetheless continue to hire large numbers of SWEs while paying double the market rate.

Tech companies have laid off over 200,000 people since the beginning of 2025. Even putting aside the fact that (from what I understand) over half of Anthropic and OpenAI's employees are in non-engineering roles, if you assumed every employee was an engineer, Anthropic and OpenAI could triple their staffing levels and it still wouldn't even fill a quarter of the void.

Yes that’s the right source. There would be no recovery in SWE market after the higher interest rates killed it if LLMs had any major impact on SWE employability.

It all feels to me similar to how spectators or laypeople judge pro sports.

Don’t quote me on this, just trying to make a point:

They’ll say you need perfect symmetry to do well in sports, which is highly correlated to development stability in the womb; higher symmetry = perfect development.

Then after some years, news will come: Bruce Lee’s one leg is shorter than the other by a significant amount, and Usain Bolt has a similar asymmetrical development.

Then they’ll flip-flop around their initial argument by claiming that they are outliers so the general rule need not apply.

brother just build what you find interesting and it may work :)

the idea that llm's can't help if you're missing domain knowledge is crazy.

There's a lot of people agreeing and disagreeing with the article, but on what grounds? How do you know "domain expertise" is a "moat"? Vibes? Has there been ongoing, persistent attacks by AI on domain expertise where we can say the moat holds, economically speaking? So far it seems quite the opposite.

So far the evidence seems to be pointing to a different adage, Sutton's Bitter Lesson, which (generalized) says to not bring human expertise to a problem that can be "solved" with unfathomable volumes of data. Because the latter has historically slaughtered the former for decades. But somehow people believe this time it's different?

I will counter there is one thing that is a persistent moat, and it's not domain expertise; it's sales. Convincing other humans to part with their money. Humans have shown they will trust a person/human touch to part with their money more than an AI.

But I'm not convinced today's AI or tomorrow's won't be able to replicate domain expertise in domain X for any X.

I work as an analyst, and our group has roughly 20% analysts with strong technical (software engineering) skills, and the rest are more traditional analysts / domain experts.

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.

This sort of thing has Microsoft Access vibes about it. All AI is enabling is domain experts to spin up their own software systems with no understanding of how the systems should be put together.

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.

It was never about the code.

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.

IDK, there's a tipping point where at best domain expertise without skill leads to a LOT of tech debt.

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.

You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed.

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.

Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code

"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.

Are you kidding me. What has domain got to do with efficiency and scalability.

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.

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.

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.

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.

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.

Writing scalable and efficient programs are extremely hard. This matters for serious projects but for small projects, honestly who cares.

The almost all problems are "small", by your standards. Giant market.

Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code.

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.

Seriously doubt you ever did serious financial math.

Coding is way easier.

Lol truly. A short list of just a few things that haunt my dreams: Distributions, American/European waterfalls, Carried interest, Management fees, and basically every single detail about Master feeder fund economics

Funny. Sure. Kernel development and truly scalable architectures must come easy for you. Management fees must be so hard. :)

“Teaching and engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.”

Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!