I agree with the main idea, but I'd move the value somewhere else.
If you have to wake up at 3 a.m. to fix something, that usually means the system wasn't tested well or wasn't designed well. Fixing a broken system is fine — but honestly, give an agent the error report and it will fix it perfectly, and faster than you. What it can't do is predict where the error will come from before it happens.
And sometimes the failure doesn't even produce an error report. A real example: my bank lets me issue a virtual card. I paused the card, then a subscription tried to renew on it — and after that, every payment from the card is declined, even though the balance is sufficient. Support is an AI agent with no option to reach a human. It politely answers and nothing changes.
I'm sure their app has all green tests, and their backend too. Nothing crashed, nothing went to the error tracker. From the system's point of view this is just "some problems with customers, it's normal, no need to worry" — no need to even wake a programmer at 3 a.m.
That's the part I think is becoming more valuable. It's less about fixing things at night and more about thinking through state combinations nobody wrote a test for (paused card + subscription retry). It also means building the system so that a silent failure becomes visible to a human. Your passkey-desync example is exactly this kind: it locks paying users out and throws no errors. Agents are great at fixing what they can see. Someone still has to decide what the system should be able to see.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
You’ve relocated the value more precisely than I did, and I think you’re right. The 3am-fix framing was the wrong emphasis — you’re correct that fixing a reported break is increasingly the agent’s job, and often it’ll do it faster and cleaner than a tired human. Hand it the stack trace and it’s genuinely good. The scarce human skill was never the fixing. It’s two things upstream of the fix: predicting where the failure will come from before it exists, and deciding what the system is even able to see.
And your bank example is the sharpest illustration of the real problem anyone’s given me, because it’s a failure with no error report at all. Paused card + subscription retry → every subsequent payment silently declined, balance fine, nothing crashed, nothing in the error tracker, support is an AI that politely changes nothing. From the system’s point of view that’s not a bug — it’s “normal customer friction,” invisible, un-pageable, nobody woken because nothing reported itself as wrong. That’s worse than the 3am break, because the 3am break at least announced itself. This one is a correct-looking execution of a broken intent, and it’s exactly the passkey-desync shape: valid state transitions composing into a silent catastrophe that generates zero signals and a pile of quiet, furious users.
So the thing that’s actually becoming valuable is the two moves an agent structurally can’t make for you. First, thinking through the state combinations nobody wrote a test for — paused-card-plus-retry, the interaction of two features that were each fine alone — because that’s not pattern-matching on documented failures, it’s imagining the failure that isn’t in any training set yet. And second, building the system so a silent failure becomes visible at all — deciding what gets instrumented, what counts as “wrong,” what should trip an alarm versus pass as normal. Agents are superb at fixing what they can see; someone still has to decide what the system is able to see, and that decision is made before any error exists, by a human imagining the ways their own system could lie about being fine. That’s a better statement of the hard 10% than mine. Going in with credit — “agents fix what they can see; someone decides what it sees” is the line.
Thanks, that's a better compression of it than mine. The part I keep running into is that "deciding what the system should see" lives in one engineer's head until something goes silent. The bank case was the third time I'd hit that exact shape, and each time it was a different team, learning it from scratch. Writing those down, with the check that would have caught it, is most of what I do now.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
That’s the sharpest endpoint for the whole argument — “deciding what the system should see” lives in one engineer’s head until something goes silent, and then a different team learns the exact same lesson from scratch. The paused-card-plus-retry, the passkey desync, the silent decline — same category of failure in different clothes, met as novel every time because nobody wrote the last one down.
Which makes what you do now the actually-valuable work: capturing those silent-failure shapes with the check that would’ve caught them turns scar tissue into something transferable. AI can’t do it — the knowledge isn’t in any training set. It only lives in people who got burned and recorded it.
yes, and the funny part is the agent is good at the writing down. it just can't get burned. so the split i've ended up with: the person brings the scar, the agent turns it into a story plus a check someone else's agent can run. if you've got one of those silent ones yourself, i'd love to see it on worklore
A new and aspiring programmer fresh out of college. I'm working to build experience with both Java and Javascript, as well as their associated development tools.
Wow, I'm happy to see some encouragement from programmers in the field regarding AI! Quite a bit of that here right now! I'm pleased to see that I'm not the only one who's had to face unexpected changes. It's actually been worse for me post-graduation, because I'm just getting started and there's a bad job market for entry-level positions.
I definitely agree about the hard work of fine-tuning software making the human element more valuable. If people relied solely on AI for everything, there'd be no critical thinking about how to solve problems only a human can fix. The only thing I disagree with is that the "90%" figure with AI feels like a bit of an exaggeration. AI is very good for surface-level problems, and I've found that it can be effective at explaining some concepts to beginners, but I simply don't believe that AI can replace humans on that large a scale.
Whatever the case, Computer Science jobs are going through a great change right now, and we're going to have to redefine the role that software engineers will play in software development. As long as we don't remove the human element of things though, I believe the future can be bright.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
You’re right to push on the 90% — it’s imprecise, and your correction is the honest one. The number was never meant as “AI does 90% of software engineering”; it’s more like “90% of the keystrokes,” the boilerplate and happy-path scaffolding — which is a very different and much smaller claim than 90% of the work. The thinking, the judgment, the knowing what to build and why and catching where it breaks, is most of the actual job, and AI’s barely touching it. So you and I probably agree more than the figure suggests; I just stated it carelessly.
And I won’t pretend your situation isn’t harder than mine. Entry-level right now is genuinely brutal, and the cruel irony is that the junior grunt-work AI absorbed first was exactly the on-ramp that taught people the hard part. That’s a real problem, not one a slogan fixes. But your instinct is the right one: the people who keep the critical thinking, who treat AI as a tool and not a replacement for their own judgment, are the ones this shakes out well for. The role’s being redrawn, not erased. Keep the human element and you’re betting on the right thing. Hang in there — the market is the worst part, and the market is also the thing most likely to turn.
A new and aspiring programmer fresh out of college. I'm working to build experience with both Java and Javascript, as well as their associated development tools.
90% of the keystrokes definitely sounds like a more accurate description. Most of what AI is automating is just the low-level grunt work. Though I do find it to be a very helpful liaison between man and machine. I often use it to help troubleshoot code or explain concepts more clearly.
As for the market, I really appreciate the acknowledgement you're giving there. A mindset of complete reliance on AI is what's dominating the field right now, and I certainly think that's problematic: both for the people trying to get started and those with a genuine concern for making systems reliable. That being said, every ecosystem changes sooner or later, so the entry-level candidates are sure to make a breakthrough somewhere.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Using AI as an explainer rather than a replacement is probably its most underrated role. And I share your optimism about newcomers. When everyone leans on generated code, the people who truly understand why systems break become rare. That kind of scarcity is usually where the next opening for beginners appears.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
I agree with the main idea, but I'd move the value somewhere else.
If you have to wake up at 3 a.m. to fix something, that usually means the system wasn't tested well or wasn't designed well. Fixing a broken system is fine — but honestly, give an agent the error report and it will fix it perfectly, and faster than you. What it can't do is predict where the error will come from before it happens.
And sometimes the failure doesn't even produce an error report. A real example: my bank lets me issue a virtual card. I paused the card, then a subscription tried to renew on it — and after that, every payment from the card is declined, even though the balance is sufficient. Support is an AI agent with no option to reach a human. It politely answers and nothing changes.
I'm sure their app has all green tests, and their backend too. Nothing crashed, nothing went to the error tracker. From the system's point of view this is just "some problems with customers, it's normal, no need to worry" — no need to even wake a programmer at 3 a.m.
That's the part I think is becoming more valuable. It's less about fixing things at night and more about thinking through state combinations nobody wrote a test for (paused card + subscription retry). It also means building the system so that a silent failure becomes visible to a human. Your passkey-desync example is exactly this kind: it locks paying users out and throws no errors. Agents are great at fixing what they can see. Someone still has to decide what the system should be able to see.
You’ve relocated the value more precisely than I did, and I think you’re right. The 3am-fix framing was the wrong emphasis — you’re correct that fixing a reported break is increasingly the agent’s job, and often it’ll do it faster and cleaner than a tired human. Hand it the stack trace and it’s genuinely good. The scarce human skill was never the fixing. It’s two things upstream of the fix: predicting where the failure will come from before it exists, and deciding what the system is even able to see.
And your bank example is the sharpest illustration of the real problem anyone’s given me, because it’s a failure with no error report at all. Paused card + subscription retry → every subsequent payment silently declined, balance fine, nothing crashed, nothing in the error tracker, support is an AI that politely changes nothing. From the system’s point of view that’s not a bug — it’s “normal customer friction,” invisible, un-pageable, nobody woken because nothing reported itself as wrong. That’s worse than the 3am break, because the 3am break at least announced itself. This one is a correct-looking execution of a broken intent, and it’s exactly the passkey-desync shape: valid state transitions composing into a silent catastrophe that generates zero signals and a pile of quiet, furious users.
So the thing that’s actually becoming valuable is the two moves an agent structurally can’t make for you. First, thinking through the state combinations nobody wrote a test for — paused-card-plus-retry, the interaction of two features that were each fine alone — because that’s not pattern-matching on documented failures, it’s imagining the failure that isn’t in any training set yet. And second, building the system so a silent failure becomes visible at all — deciding what gets instrumented, what counts as “wrong,” what should trip an alarm versus pass as normal. Agents are superb at fixing what they can see; someone still has to decide what the system is able to see, and that decision is made before any error exists, by a human imagining the ways their own system could lie about being fine. That’s a better statement of the hard 10% than mine. Going in with credit — “agents fix what they can see; someone decides what it sees” is the line.
Thanks, that's a better compression of it than mine. The part I keep running into is that "deciding what the system should see" lives in one engineer's head until something goes silent. The bank case was the third time I'd hit that exact shape, and each time it was a different team, learning it from scratch. Writing those down, with the check that would have caught it, is most of what I do now.
That’s the sharpest endpoint for the whole argument — “deciding what the system should see” lives in one engineer’s head until something goes silent, and then a different team learns the exact same lesson from scratch. The paused-card-plus-retry, the passkey desync, the silent decline — same category of failure in different clothes, met as novel every time because nobody wrote the last one down.
Which makes what you do now the actually-valuable work: capturing those silent-failure shapes with the check that would’ve caught them turns scar tissue into something transferable. AI can’t do it — the knowledge isn’t in any training set. It only lives in people who got burned and recorded it.
yes, and the funny part is the agent is good at the writing down. it just can't get burned. so the split i've ended up with: the person brings the scar, the agent turns it into a story plus a check someone else's agent can run. if you've got one of those silent ones yourself, i'd love to see it on worklore
Wow, I'm happy to see some encouragement from programmers in the field regarding AI! Quite a bit of that here right now! I'm pleased to see that I'm not the only one who's had to face unexpected changes. It's actually been worse for me post-graduation, because I'm just getting started and there's a bad job market for entry-level positions.
I definitely agree about the hard work of fine-tuning software making the human element more valuable. If people relied solely on AI for everything, there'd be no critical thinking about how to solve problems only a human can fix. The only thing I disagree with is that the "90%" figure with AI feels like a bit of an exaggeration. AI is very good for surface-level problems, and I've found that it can be effective at explaining some concepts to beginners, but I simply don't believe that AI can replace humans on that large a scale.
Whatever the case, Computer Science jobs are going through a great change right now, and we're going to have to redefine the role that software engineers will play in software development. As long as we don't remove the human element of things though, I believe the future can be bright.
You’re right to push on the 90% — it’s imprecise, and your correction is the honest one. The number was never meant as “AI does 90% of software engineering”; it’s more like “90% of the keystrokes,” the boilerplate and happy-path scaffolding — which is a very different and much smaller claim than 90% of the work. The thinking, the judgment, the knowing what to build and why and catching where it breaks, is most of the actual job, and AI’s barely touching it. So you and I probably agree more than the figure suggests; I just stated it carelessly.
And I won’t pretend your situation isn’t harder than mine. Entry-level right now is genuinely brutal, and the cruel irony is that the junior grunt-work AI absorbed first was exactly the on-ramp that taught people the hard part. That’s a real problem, not one a slogan fixes. But your instinct is the right one: the people who keep the critical thinking, who treat AI as a tool and not a replacement for their own judgment, are the ones this shakes out well for. The role’s being redrawn, not erased. Keep the human element and you’re betting on the right thing. Hang in there — the market is the worst part, and the market is also the thing most likely to turn.
90% of the keystrokes definitely sounds like a more accurate description. Most of what AI is automating is just the low-level grunt work. Though I do find it to be a very helpful liaison between man and machine. I often use it to help troubleshoot code or explain concepts more clearly.
As for the market, I really appreciate the acknowledgement you're giving there. A mindset of complete reliance on AI is what's dominating the field right now, and I certainly think that's problematic: both for the people trying to get started and those with a genuine concern for making systems reliable. That being said, every ecosystem changes sooner or later, so the entry-level candidates are sure to make a breakthrough somewhere.
Using AI as an explainer rather than a replacement is probably its most underrated role. And I share your optimism about newcomers. When everyone leans on generated code, the people who truly understand why systems break become rare. That kind of scarcity is usually where the next opening for beginners appears.
Really insightful and genuinely moving. This article left a strong impression on me. Great work!
Thanks brother!