One of the things I say is when I’m on my soapbox is: we are all engineers. We have different tools in our toolbox to solve problems. We get paid to solve problems, not (for example) write software. Software is just a tool.

Have you?

That said, they do make excellent tools to quickly try out new ideas and dive into them; they can even be great learning accelerators if you have a curious mind.

If AI becomes the interface, then we will a layer of abstraction above programming languages themselves. Which is kind of wild.

(I don't pretend this is a novel idea. I'm just not that plugged into AI discourse.)

If that's true, any statements defining what is necessary to do should be ignored in that context. I'm still interested in hearing about what people tried, what results they think they saw, and then trying to apply those findings to my own processes.

Which is to say I don't think the pontificating is pointless, but as statements of Real Truth, I agree they're likely wrong. We're too early in the game.

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?

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

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!

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!

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

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.

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 problem is that more and more people are getting convinced by the AI's that they're domain experts when they're really not.

That engineer still is indispensable. Any organization foolish enough to replace such a person with an LLM is going to find itself in deep water when the pile of hallucinations becomes too much to endure.

Maybe we can grab a coffee.

In 2018 I witnessed one guy with no prior coding experience who built a tool that after a month of coding was making very decent money (more than me), just because he was aware of a particular niche.

He showed me parts of his code and it was as bad as my first program, but his was solving a real life problem.

I think AI is going to force most software engineers to pick up this skill in some form. Building is easy; knowing what to build is the hard part.

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???”

The market is big.

This is the moat. It was before AI and still is.

They are already significantly better than humans at persuasion (according to a study from Princeton).

What do you mean by this? Most human white collar workers still have their jobs. I can't see the future, but yes, so far, human expertise is doing ok.

We'll see what happens in 2027, and 2028, and...

Knowing "too much" and not knowing what belongs to the core and what is a secondary detail is exactly a lack of domain expertise.

I am still bothered that domain experts still keep confusing closing orders with generating a delivery note, or stopping to say articles when they mean a product or a product when they mean an item.

Writing good specs require lots of domain knowledge but a very engineeristic approach these people just don't have.

Though I'll say I don't buy the stuff about AI "democratizing" development since making it much more capital-intensive kind of has the opposite effect for anybody doing dev work at home.

I'm not worried about non-technical vibe coders taking my job. I'm worried about psychotic VCs and CEOs putting me on the street in the name of "optimization" of "lower value human capital".

I've been working on something relatively large and greenfield recently.

A big chunk of my time is spent thinking about the hard parts. The raw information processing rate needed to keep up with the state of the project is high.

It feels almost like mental athleticism, whereas coding used to be a rather chill activity.

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.

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.

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

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

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.

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

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.

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.

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.

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.

The dunning kruger effect is in full swing as people think AI replaces the domain expert need.

Most of the value in the expert isnt the 80% but the tail 20% or 10% where AI fails. For a one of personal app or website, 80% is plenty but only that.

I've heard this story at least 3 times already:

- Domain expertise combined with outsource could replace expensive US SWE

- Domain expertise combined with SWE could replace QA

- Domain expertise combined with SWE could replace infra engineers

Why is everyone so preoccupied with replacing someone with someone instead of doing their fucking job?

In other words, there won't be 20-year-old code in this future.

We'll see if that comes to pass, but there's a lot of money betting that will happen; enough to where people will disregard what the downsides are.

Programming is the easiest part! (c) decade+ experienced senior developers

if you’re actually building these things, you know they and the CEOs they’re hearing from are all 6 months behind. the executive’s frantic pivot to shove “AI” down everyone’s throat didn’t pan out in one quarter and had nothing to do with the actual concept at all

that, and every industry is different. I wouldn’t listen to analysts, I’m in an industry that even Anthropic thinks wont be touched by AI (even though they can read ours and everyone else’s sessions)

all public discourse is just flat wrong, and just like every week this year, you’re just going to wake up seeing a new AI capability headline that makes you question your role in society. So play devil’s advocate all you want, the silver lining is that there’s more work to do than ever before and more of it can be tackled at once

Coding is way easier.

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.

By your logic anyone who's not in the top 10% of intelligence can't offer anything. The world keeps spinning.

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

That's just nonsense, nobody will work with 8 year old (it's illegal, to start with). Go touch grass.

One of the reasons I'm increasingly skeptical of this prediction is that I've now lived past a few of the dates I heard people put on the achievement of this level of superintelligence in previous years.

This hasn't been the case for at least a decade. Long before LLMs.

But then again, logic is really a lot more discrete and well defined and easily expressed with traditional computing than LLMs are (which are probabilistic systems instead and as such require large knowledge bases).

We can observe that at a couple hundred billion parameters they behave similarly to a point (in the sense that they can produce similar results), but the challenge is really in understanding the problem's multifaceted structure and competing needs and priorities.

I have been "agentic coding" since Sonnet 3.5 and after this paper came out, it became my bible:

https://github.com/adobe-research/NoLiMa

Last I checked, all models suck as you fill the context window. "Context engineering" is how you do this whole thing.

I had the displeasure of working with those types. One of them replies to any question or challenge to a technical problem emerging from the PRs they posted with variants of "I've worked here for over a decade, this is how we do things". And then proceeds to argue things like defensive programming is a code smell because it means developers don't trust themselves.

I cannot envision any healthy, effective engineering environment where developers don't periodically switch between projects.

This is a complete unrealistic assessment. Who do you think vibecoders are? They are yesterday's software developers using today's tools.

The people who manually write their PRs are also not giving a fuck when they break production code with spaghetti code that later has to be thrown out and rewritten. They are the same people.

The key difference is that now their output volume is much greater, and they iterate much faster. They roll out plenty of bullshit, but it also hits the fan much faster and triggers fixes at a higher rate.

People hate on vibecoders because they do exactly what your average developer does but at a much higher rate.

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.

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

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

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.

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?

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

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.

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

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

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.

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?

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.

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

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

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.

I found AI to be pretty bad with like a bare bones code base without solid patterns in place already. It works but it's just monolithic files galore. use effects hooks everywhere. Nasty state situations with poor data practices. Security vulnerabilities up the wazoo.

It's weird to have this conversion with them. Like yeah your code works but it's so tangled up it's hard to reason about where to start to begin to unwind it all sometimes.

It can be done but cleaning up someone else's slop is the exact reason why I hate AI. It was hard enough to review great code and be critical, honest, and fair but we knew it was an essential part of the process, helped build shared understanding, and was a way to learn from one another.

Whereas throwing in jumbled garbage to review just feels like a waste of our brain cells we spent decades earning by embracing the craft.

It's similar to the 80/20 rule. When you're coding and designing from the hip, you'll do pretty well for awhile, but as you near completion, you can't quite tie up all the loose design ends. That's the part where it's probably better to just design fully to 100% first and then build, which is closer to what happens when the roles are separate. At least in my experience. I will say though that that part where you're designing in code (productively or wastefully) is pretty fun. At least until you hit the wall and get frustrated with how often you've deleted and rewrote the same thing ten times.

Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.

But mental discipline required to write efficient and scalable code is insane that most domain expertise is feeble by comparison.

Now I’m basically expected to do what my boss wants me to do every minute of the day, it’s gotten much more micromanaged.

Before: "I learned very little this year, because I was placed in charge of the same stuff, and I've already learned most of what I could from tinkering with that code, stepping through its architecture, and dealing with those recurring problems."

Soon: "I learned very little this year, because I don't deeply interact with anything, I just pull the lever on the babbling slot-machine until I get lucky and things seems to quiet down."

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.

Do you take into account recent layoffs of Meta (8k people), Block (4k people) and others?

It is on a scale that it is required now. Previously you could say "it'll take me a week to decipher the mess", now they can just say "can't you use an agent to make it fast?".

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.

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.

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

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 vibe coders aren’t “right”, they just get lucky.

Here’s a secret: I haven’t really bothered reviewing any PRs since September of last year or so. I just click approve and don’t even read it. It has been way less stressful for me.

Do bugs get through? Sure. But someone will just come in and vibe it out anyway. And I have yet to see a vibe coder or anyone who approved their flawed work get any repercussions. So yea, it doesn’t matter.

No one’s going to come after you asking “why did you approve this shitty PR?” And if they do you can forward it to the author and ask why they wrote a shitty PR. But that just doesn’t happen. It doesn’t matter.

"don't want to buy tools, and don't want to get shit on their hands"

Thats closer to the truth. The rest of your post is fluff. Its pure economics, not rocket science.

You can read all the plumbing books, but you need to get your hands dirty a few times, mess it up and fix it, to get mentally comfortable and efficient with the work

But OP wasn't talking about solving optimalization problems, but understanding the rules of a business domain.

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.

Though the market so far has had a lower limit on "worse". We're finding out how low we can go before consumers start valuing quality again.

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.

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

It definitely won’t be CEOs and managers not firing their buddies

I mean, sure. But there have always been people teaching themselves to program too. In the end it's a pretty small population.

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?

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.

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.

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

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.

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?

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.

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.

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.

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.

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.

Should AI make you really good at frontend development?

You could've just written this sentence and dropped the rest. I understand your vindictive, "justice", self-hate line of thought, but not it's not a healthy way to live. Get help.

Being in the weeds of the trade expands the lens of capabilities so I’d give the upper hand to someone more deeply aware of the tech vs not. even though that in itself is still not sufficient.

I've never used breakpoint debugging, was always a printf debugger. And now an agent can do that loop for me.

Prompt is usually something along the lines of:

>I would expect the behavior of this to be [X] - instead I'm observing [Y]

And the agent will form hypothesis, place printf statements, compile, and scrape logs on loop - each loop ruling out hypothesis or narrowing down what portion of the code is responsible for the unexpected behavior.

It has been able to pin-point the exact line(s) of code responsible every time I've reached for it so far.

From what I've seen they're more likely to run a python -c "import your_code; your_code.do_stuff()" experiment to figure out what's going on though.

A key feature of AI coding assistants and coding agents is troubleshooting. It turns out that LLMs excel at pattern matching, specially when coupled with feedback signals. It turns out that troubleshooting represents just that. A few years ago people searched the likes of stack overflow to fix problems, and it turns out LLMs can do the equivalent of that much faster.

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

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.

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

Facades and stranglers are massively useful patterns, and help explain concepts to the layman.

Personally I've never been patterns over everything, so I'm not going to now knee jerk and say no patterns ever.

There's a time and a place for everything.

edit Fuck. A reread on that and I sound like AI. Updated

The business goal is that the site is slow. That gets fixed by the non-technical vibecoder for the cost of however many tokens. Why look for outside help (aka me) if there's no need to and the AI can do it all?

There's a whole world of opportunity that lives below complex multi-tenant applications that have to deal with high TPS.

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

This is an extreme, straw man argument. And here's the thing: I don't know a home gamer who framed a house. But I do know tech-savvy people who have used AI to build web apps that they have launched and been able to get customers to pay for.

Not every tech-savvy person has the ability to do this but the whole "you can't do that if you're not a software developer" argument looks to me like a denial mechanism more than a reflection of reality. People are doing it because the AI tools have advanced to the point where they can.

No, you do not become a really good FE dev from having used websites with AI in the mix.

Why should chess be different?

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

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

I don't have any automated LLM scanners, but I do frequently have ChatGPT run searches for me with questions like "Find the most credible accounts of the recent Oracle layoffs, how they went, rationale, problems caused".

The sole exception to that is that, back in the very early days, troubleshooting IE6 really required a debugger. But everything else, from memory leaks to thread hang issues to deadlocks, testing is better.

It's "just another tool", sure. But one that is so powerful that some things that used to take a day now take minutes, or ones that used to take a week now take a day. And I get even more praises now, along with more time to focus on understanding the needs and controlling quality. For me it's not really about stuffing as much features as possible, but providing better software.

I'm glad this happened after 25 years in my career. I believe I'm in a privileged position where I can benefit from LLMs and still have the knowledge to effectively correct the machine or go back to "manual mode" if anything goes wrong.

With all due respect, this sounds like just another version of the arrogant, scared attitude that seems to be more and more prevalent among software folks these days.

Is it really hard to imagine that there are tech-savvy people who are smart and motivated but don't have training as software developers, who are now capable of using AI to build and ship things?

In other words, AI doesn't allow any "any idiot" to build commercially useful software. What it does is allow smart people who aren't software developers and who don't want to become software developers professionally to, with a much shorter learning curve and on a much faster time scale, take their ideas and build and ship functional software.

But also to the original Simon's point that using LLM does not a good engineer make — how we make one is still on us with 10+ years (I've got "only" 20) of experience to figure out now that LLMs are here!

Implicit definition of a good engineer is the one who chooses the right balance between effort, complexity, performance to build a working software system for a business need that can be evolved according to (unforeseen!) future business needs at reasonable cost.

I would argue that the non-developers who are able to use AI to build, ship and sell software aren't "self-taught software developers". The biggest reason is that they're effectively not learning how to code in any meaningful way. They don't need to. AI is getting "so good" that they can prompt their way to functional software without the same level of knowledge and skill that was required previously to do the same.

We can discuss the limits and risks of this, and you can criticize AI's output, but the reality is that people are actually doing this and having some success. First hand, I've seen a former colleague who is a skilled digital marketer with no development experience launch a web app for a niche market and sell it to a number of customers.

I don't understand why you're so interested in extremes (your skilled versus deskilled hyperbole). Is it really so hard to contemplate that AI is disrupting the market for software development? It's not that it has eliminated the need for intelligence and skill; it's that it is allowing a larger number of people to do something that previously required a different set of skills that was much more difficult and time-consuming to acquire.

To use Silicon Valley speak, AI is democratizing software development. That doesn't mean every idiot can build and deploy a functioning web application; it does mean that a growing number of intelligent, motivated non-developers can.