💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Introduction — Two Essays Published the Same Week

In late May 2026, developer community timelines produced an interesting coincidence. The Stack Overflow blog published "Artisans and builders", and almost simultaneously a personal blog post titled "LLMs are eroding my software engineering career and I do not know what to do" took over the Hacker News front page and sparked heated discussion on GeekNews.

The two essays treat the same phenomenon at opposite temperatures. The former calmly divides AI-era development into two identities — artisan and builder — and forecasts the future with composure. The latter is a raw confession of anxiety from a senior developer who feels that skills built over more than a decade are being devalued overnight by LLMs.

The Hacker News comment section was the most interesting part. Hundreds of comments split between "I feel exactly the same" and "your value was never typing code". This post uses the two essays as axes to redefine developer identity in the AI era, and to convert anxiety into executable strategy.

The Two Arguments — A Calm Taxonomy and a Desperate Confession

The argument of Artisans and builders

The core distinction in the Stack Overflow post:

- A builder's goal is the artifact. Code is a means; a working product is the end. AI tools are the greatest gift in history for builders.

- An artisan values the process of making and the quality of the made thing. Artisans understand systems deeply, pursue elegant solutions, and dig into the internals of their tools.

The author's forecast is polarization. AI has effectively removed the entry barrier for builders, while simultaneously raising the scarcity value of artisans — the people who can fix the enormous volume of AI-built artifacts when they break. The dangerous place is the middle: positions with neither artisan depth nor builder speed get squeezed first.

The argument of LLMs are eroding my career

The opposite essay starts from emotion, not theory. The author says, roughly:

- I am someone who built identity and self-worth on writing code well.

- Code that used to take me a day now takes an LLM ten minutes. I no longer know what differentiates me.

- My company has made AI tool usage effectively mandatory, and I feel like I am watching my skills melt in real time.

- People say learn more, but the tools improve faster than I can learn. I do not know where to run.

The reason this essay spread explosively is clear: it precisely articulated a feeling many developers could not say out loud. In 2026, with agents like Claude Code and Codex autonomously executing multi-hour tasks, this anxiety belongs to no small minority.

The two essays, side by side

| Dimension | Artisans and builders | LLMs are eroding my career |

| --- | --- | --- |

| Viewpoint | Aerial view of industry structure | First-person lived experience |

| Temperature | Analytical, composed | Urgent, grieving |

| Core claim | Identity will polarize | Existing identity is collapsing |

| Stance toward AI | Tool and structural force | A presence eroding self-worth |

| Offered solution | Align as artisan or builder | None (ends with a question) |

| What it gives readers | A map | Solidarity |

The interesting part: the two essays nearly agree on the facts. Both diagnose the same collapse in the value of code production. They diverge afterward — one points to where value has moved, the other fears being unable to follow the move. The rest of this post deals with the gap between map and solidarity: the problem of execution.

What Actually Changed — Democratization and Reappraisal

Overlaying the two essays reveals the substance of the change. What changed is not developer value but the distribution of value.

Value curve before AI Value curve after AI

value | ____ value | __

| ___/ \___ | / \

| / \ |/ \

| _/ \_ | \____ ___

|/ \ | \______/

+---------------------> +--------------------->

entry middle expert entry middle expert(artisan)

gentle skill-to-value slope middle collapses, both ends rise

The democratization of building

Start with the positive change: anyone can build now. Product managers build internal tools themselves, designers validate prototypes in code, and solo founders ship products without contractors. The 2026 hackathon scene is symbolic: hardware hackathons are back, half the participants are non-CS, and demo quality matches a seed-stage startup from five years ago.

Before being a threat, this is market expansion. The total volume of software being created is exploding — and created software inevitably breaks, must be integrated, and must scale.

The reappraisal of the artisan

That is exactly where artisan value gets reappraised. As the volume of AI-generated code grows, the scarcity value of the following abilities rises.

1. Deep debugging. AI often cannot explain failures in its own code. Timing issues in distributed systems, memory leaks, and driver-level problems are still solved by people who understand the system across its layers.

2. System-level understanding. AI writes the individual code, but deciding where to cut service boundaries and where to guarantee data consistency remains the job of someone holding the whole system in their head.

3. The ability to take responsibility. In regulated industries, explaining to an auditor why this code is safe — and signing for it — remains human work. The June 2026 npm supply chain attack that reached Red Hat Cloud Services showed once again that the bottleneck is verification depth, not generation speed.

A timeline of shifting sentiment, 2024-2026

It is worth noting that this debate did not appear out of nowhere. A rough time series of community sentiment:

2024 H1 2025 H2 2025 H1 2026

| | | |

"autocomplete "agents are "team rollouts, "long autonomous runs,

got good" sending PRs" role reshuffling" identity debate erupts"

| | | |

novelty -> productivity -> organizational -> existential questions

excitement friction (artisan vs builder,

(review debt, career erosion

junior hiring cut) confessions)

The defining feature of 2026 is that the debate has descended from tools to identity. Nobody asks which tool is best anymore. Tools became the premise, and the question became: so who am I now. That two essays exploded in the same week is not coincidence — it is a signal that the whole community arrived at this question together.

Scenario — A Ten-Year Payments Backend Engineer

To avoid abstraction, let us construct a concrete person. K is a hypothetical backend engineer with ten years of experience, mostly building payment and settlement systems. K's anxiety is specific: payment API integrations, settlement batches, webhook handling — K's specialties — are now produced by an agent in an hour.

But decomposing K's assets changes the story.

| K's asset | AI replaceability | Why |

| --- | --- | --- |

| Writing API integration code | High | Patterned work, generatable from docs |

| Implementing settlement batches | High | Generatable given a precise spec |

| Double-spend edge case knowledge | Low | Tacit knowledge earned through incidents |

| Per-PSP settlement quirks and traps | Low | Undocumented domain knowledge |

| Financial compliance experience | Low | Territory bound to trust and liability |

| Decision-making during incidents | Very low | Fusion of context, authority, accountability |

Only the top two rows of K's assets are threatened. But because K has spent ten years describing personal value in terms of those top two rows, it feels like losing everything. The redefinition goes like this: K is not someone who writes code fast, but someone who knows what a system that does not leak money looks like. And in a world where agents produce payment code in an hour, the value of the person who can tell whether that code leaks money goes up, not down.

K's strategy is not escape but redeployment: combine domain knowledge with AI tools, build evals that verify payment systems, codify the team's payment code standards in agent context documents, and become the final gatekeeper for the payment integration code AI mass-produces.

K's actual artifacts — moving domain knowledge into code

If K executes the hybrid strategy, what gets built? The first artifact converts payment-domain tacit knowledge into a context document agents can read.

PAYMENTS.md — required reading for agents touching the payments module

Absolute rules

- Every payment request takes an idempotency key. Never write a payment

API without one.

- No floating point in money math. Integers in the currency's minor unit only.

- External PSP calls: 5 second timeout; retries only in idempotent sections.

- Refunds only after validating the original transaction state. See the

state machine diagram.

Recurring traps (based on real incident history)

- PSP A delivers webhooks up to 3 times. Receiver-side idempotency required.

- PSP B settlement amounts include VAT, PSP A's do not. Mind comparisons.

- The cancel API processes next-day if called after business-day cutoff.

State transitions (anything else is a bug)

READY -> PAID -> (CANCELLED | REFUND_PENDING -> REFUNDED)

The second artifact is an eval that mechanically verifies agent-written payment code.

payment_evals.py — automated checks for AI-generated payment code

CRITICAL_PATTERNS = [

(r"float\(.*(amount|price|fee)", "float used for money - use integer minor units"),

(r"requests\.(post|get)\((?![^)]*timeout)", "external call without timeout"),

(r"def\s+(charge|pay|refund)\w*\((?![^)]*idempotency)",

"payment function without idempotency key parameter"),

]

def eval_payment_code(source: str) -> list[str]:

findings = []

for pattern, message in CRITICAL_PATTERNS:

if re.search(pattern, source):

findings.append(message)

return findings

def test_no_critical_findings():

for path in changed_payment_files():

assert eval_payment_code(read(path)) == []

What these two files symbolize matters. While K's ten years lived only in K's head, the value showed up only when K personally wrote code. Once moved into documents and evals, K's standards apply to every line of code even when agents produce a hundred times more of it. This is the leverage conversion of the domain expert.

Where Am I — A Self-Diagnosis Checklist

Before choosing a strategy, diagnose your current position. Answer yes or no.

[Artisan axis]

1. In the past year I found the root cause of an incident others gave up on

2. I can explain the internals of my main stack (framework source, DB engine)

3. I frequently spot working-but-dangerous parts in AI-generated code

4. I approach performance problems with measurement, not guessing

[Builder axis]

5. I can turn an idea into a working demo within a week

6. I have often prioritized shipping speed over technology novelty

7. I think about getting user feedback before code quality

8. I have my own workflow for delegating tasks to AI agents

[Domain axis]

9. I can list incident cases in a specific industry/domain without notes

10. I know cases where regulation or convention changes the technical answer

11. I can talk to domain experts (non-developers) in their language

12. People inside or outside my company seek out my domain knowledge

Three or more in an axis means that axis is your strength. Strong artisan axis suggests the deepening path; strong builder axis the expansion path; three or more on the domain axis means you already hold the raw material for the hybrid path. Fewer than two on all three axes is exactly the middle zone both essays warn about — a signal to pick one axis and start investing deliberately.

Comparing Career Moves — Three Paths

For someone in K's position, the available paths reduce to three.

| --- | --- | --- | --- |

All three paths are valid, but as of 2026 the scarcest supply in the market is the third. Many people know a domain; many people use AI tools; very few can build a system that verifies AI output against domain standards.

What must be avoided is not choosing. The middle zone — doing the same work as yesterday with neither artisan depth, nor builder speed, nor hybrid synthesis — is the danger area both essays point at.

A Quarterly Action Plan — One-Year Roadmap

Once direction is set, execute. Using the hybrid path as the example, here is a four-quarter plan assuming four hours per week outside regular duties.

Q1 — Diagnosis and foundation

- Write your asset inventory: like K above, build the table decomposing your skills by AI replaceability.

- Establish one AI agent workflow at work: start small — review assistance, test generation.

- Begin documenting your domain's tacit knowledge: one incident, edge case, or trap per week.

Q2 — Combination experiments

- Convert domain knowledge into agent context: reshape the Q1 notes into CLAUDE.md or AGENTS.md format, feed them to the agent, observe the quality shift in output.

- Write your first domain-specific eval: a verification script that catches the fatal mistakes of your field (for payments: idempotency violations, rounding errors).

- One internal share-out: present, however small, to make the hybrid position visible.

Q3 — Expanding leverage

- Team-level adoption: propose promoting your personal workflow to team standard.

- Start external output: two blog posts or one meetup talk. Build identifiability in the market.

- Reinforce depth: systematically study one foundation adjacent to your domain (for payments: distributed transactions, idempotency design).

Q4 — Consolidating the position

- Quantify outcomes: before-and-after numbers for review time, defect rate, throughput.

- Refresh career documents: rewrite resume and portfolio from the viewpoint of system quality guarantor, not code producer.

- Decide next year's direction: with a year of data, choose among deepening, expanding, or moving.

Two governing principles. First, every quarter must leave externally verifiable artifacts (documents, talks, numbers). Second, never make tool learning itself the goal. Tools change every quarter; domain knowledge and verification systems compound.

Converted into a weekly routine, the quarterly plan looks like this.

| --- | --- | --- | --- |

| Mon | Document 1 piece of domain tacit knowledge | 30 min | Context documents |

Four hours a week, all directly tied to your job, so much of it fits inside working hours. What matters is not the four hours but the structure: four kinds of assets each tick up by one every week.

Resume and Interviews — Proving the Redefined Value

If you changed direction, change the language you show the market. Here is how to write for what has actually changed in 2026 hiring.

First, move from output statements to judgment statements.

Old style (production-centric):

- Built new payment module and integrated 3 PSPs

- Developed settlement batch system handling 5M records daily

2026 style (judgment and leverage-centric):

- Built payment-domain verification system (12 evals, context docs),

blocking 9 payment-related defects per quarter in AI-generated code

- Designed agent collaboration workflow cutting team payment feature

lead time 60 percent while holding incident rate flat (data on hand)

- Root-caused 5 PSP settlement mismatch incidents and designed

recurrence prevention

Interview questions are shifting along the same axis. As coding test weight shrinks, these formats are moving in:

- Review interviews: find the defects in a pile of AI-generated code

- Specification interviews: turn an ambiguous requirement into a spec

- Simulation interviews: command the response to an incident scenario

Note that the weekly routine above is direct practice for all three. The one fortunate aspect of this transition is that preparation and daily work are no longer separate.

The Organizational View — Reappraising Senior Value

This is not only an individual problem. Organizations face the same question: when a junior plus an agent produces senior-volume code, what is the senior salary paying for?

The answer progressive organizations are converging on is a redefinition of the senior role.

Traditional senior 2026 senior

- Personally writes the hardest - Makes the hardest decisions

code - Codifies quality standards into

- Guards quality through review evals and context docs, automating

- Mentors juniors 1:1 them

- Final resolver of incidents - Designs work for fleets of agents

- Still the final resolver of incidents

Note the last line. Incident response did not change. The value of the person who can command recovery when an AI-built system collapses has surged. The axes on which organizations evaluate seniors are moving from output volume to two questions. First, are there incidents that do not get resolved without this person? Second, how much of this person's judgment has been transferred into team systems (review rules, evals, context documents)?

Paradoxically, the second axis is the work of making yourself replaceable. But people who can systematize their own judgment graduate to the next tier of harder judgments — and that is becoming the new ladder of the senior career.

Institutional changes organizations are actually adopting are also worth referencing.

| Mechanism | Content | Intent |

| --- | --- | --- |

| Review gate role | Merge approval for AI code as an explicit role | Clarifying verification accountability |

| Context doc ownership | Managing CLAUDE.md-class docs as assets on par with code | Systematizing tacit knowledge |

| Incident command rotation | Senior incident-commander skill as a formal review item | Making irreplaceable skill visible |

| Agent budgeting | Managing team AI usage as budget, measuring ROI | Restraining indiscriminate generation |

What these mechanisms share: they attach roles and rewards to verification and responsibility, not production. Individual career strategy and organizational change are pointing in the same direction.

Mental Health — Working Alongside the Anxiety

The real subject of the bearblog essay is not technology but emotion. Some practical advice.

1. Raise the resolution of the anxiety. Convert the vague "I will be replaced" into a concrete list. Written out like K's table, what gets replaced is mostly a subset of your skills, not the whole. Anxiety is largest at low resolution.

2. Change the comparison target. Comparing yourself to an agent's production speed is racing a excavator at digging. Compare yourself to the you of a year ago with the same tools.

3. Anchor identity in value, not activity. I am not someone who writes code; I am someone who solves problems and answers for systems — this redefinition is not a psychological defense but a more accurate description of the job.

4. Never fully take your hands off. Keep regular sessions of coding without the agent. Partly to maintain skill, but also to protect the joy of making — the original fuel of this profession.

5. Make a place to say it. The fact that thousands resonated with the bearblog essay is itself the message. This anxiety is universal, and saying it out loud removes half its weight.

If the anxiety reaches the level of impairing daily functioning, it has moved beyond career advice and professional help is the right call. Before that stage, here is a simple weekly check.

Weekly mental check (5 minutes on Friday)

- One judgment I made this week that AI could not have made: ______

- One thing I learned this week: ______

- One thing I did this week that helped someone: ______

- One task I will drop next week (delegate to the agent): ______

If all four blanks fill up every week, what is eroding is not your career — only an outdated definition of yourself.

A Critical View — Beware Fear Marketing

Finally, a filter to apply to this entire discourse.

First, fear sells. Developer doomerism has become a content genre that converts directly into views, course sales, and tool subscriptions. Always check what the person broadcasting "learn this tool now or be left behind" is selling.

Second, the extrapolation fallacy. Predictions that extend the last two years of progress in a straight line five years out have almost always missed. Self-driving did this; no-code did this. Even if capability keeps improving, organizational adoption speed, regulation, and liability move far more slowly.

Third, the trap of productivity statistics. The statistic that AI tools increased code output and the net productivity including incidents and rework caused by that code are different numbers. Multiple field reports in 2026 point to new costs: review debt and the accumulation of code nobody understands.

Fourth — and nevertheless — denying the change itself is just another comfortable lie. The direction is clear: the value of code production is falling, the value of judgment and responsibility is rising. The moment calls for neither fear nor denial, but cold-blooded redeployment.

Frequently Asked Questions

Running internal study groups and mentoring sessions on this topic surfaces the same questions repeatedly. Brief answers.

Q1. What about an ordinary web developer with no domain like payments?

Domain does not only mean industry. Cross-cutting areas — accessibility, internationalization, performance optimization, legacy migration — are domains too. The two key conditions: is it an area where failure cases accumulate (does tacit knowledge build up), and can AI output quality be judged with that knowledge? Start by looking at where accidents happen most often in your current work.

Q2. Should I go deep first or learn the tools first?

It is a question of ratio, not order. As of 2026 tool proficiency takes weeks to catch up on, and gaps close fast. Depth and domain take years to catch up on. A 2-to-8 split of time toward depth is reasonable. But never let the tool 2 hit zero — without knowing the tools, your sense for verifying their output dulls too.

Q3. As a junior, is the chance to become an artisan disappearing entirely?

The hardest question. It is true that the traditional training ground of simple tasks is shrinking. The alternative is deliberate practice: spending a weekend doing by hand what an agent finishes in an hour, explaining agent output line by line, building a small system alone end to end. Inefficiency chosen knowingly is training; inefficiency suffered unknowingly is waste. This is the first generation that must consciously purchase the inefficiency of training.

Q4. My company pushes AI adoption but ignores verification.

Common — and paradoxically an opportunity. While the organization's attention is on production, the verification gap keeps growing, and that gap eventually sends an invoice in the form of an outage or a security incident. The person who quietly built the verification system before the invoice arrives becomes the first person the organization seeks afterward. This literally happened at many companies after the 2026 npm supply chain attack.

Q5. If I read only one of the two essays, which one?

Read the bearblog essay first. Strategy only works after facing the emotion. A plan built while skipping past the anxiety collapses the moment the anxiety returns.

Closing — Artisan or Builder May Be the Wrong Question

Overlay the two essays once more. The Stack Overflow post separated artisans from builders, but the position that survives in practice seems to lie not on either side of that division but in the ability to switch: a builder in the morning, delegating to agents for speed; an artisan in the afternoon, verifying the depths of what came back — anchored all the while to a domain.

The sense of loss the bearblog author feels is real. The era when writing code well simply was your identity truly is ending. But if that skill is not disappearing — if it is being absorbed as the foundation for larger work (judgment, verification, responsibility) — then this is closer to a promotion than a demotion. And as with every promotion, the work you excelled at yesterday differs from the work you must excel at tomorrow.

Where to stand seems clear: not beside what AI makes, but between what AI makes and the world. Whether that position is called artisan or builder matters less than the fact of standing there.

A final action summary. This week, only three things.

1. Fill out the self-diagnosis checklist and identify your axis.

2. Move one piece of tacit knowledge from your field into a document.

3. Read the bearblog essay, underline the sentences that resonate — then, at the end, open the right-hand column of the table above (the map) again.

Anxiety is a signal, not data. You have received the signal; now it is time to produce the data.

References

- Artisans and builders (Stack Overflow blog): https://stackoverflow.blog/2026/05/28/artisans-and-builders/

- LLMs are eroding my software engineering career (original): https://human-in-the-loop.bearblog.dev/llms-are-eroding-my-software-engineering-career-and-i-dont-know-what-to-do/

- GeekNews discussion: https://news.hada.io/topic?id=30264

- Hacker News: https://news.ycombinator.com/

- Stack Overflow Developer Survey: https://survey.stackoverflow.co/

- Building effective agents by Anthropic: https://www.anthropic.com/research/building-effective-agents

- Claude Code best practices: https://www.anthropic.com/engineering/claude-code-best-practices

- DORA research (software delivery performance): https://dora.dev/

- Will Larson, StaffEng (senior career ladders): https://staffeng.com/

- Camille Fournier, The Manager Path: https://www.oreilly.com/library/view/the-managers-path/9781491973882/