Old Man Yelling at the Corpus

2026-05-10T00:00:00+00:00

Rules provide system-level instructions to Agent.
—Cursor docs, “Rules”</a> </blockquote>
I keep getting stuck on that sentence. Not because of the missing article (though, yes, to “the” Agent is what English wants here), but because of what the missing article tells us about the prose underneath:
The whole document reads like a config schema that someone half-translated into English and then shipped.
Cursor is influential enough that…

its documentation will be read at scale,</li>
copied into prompts,</li>
embedded into internal docs,</li>
and eventually scraped back into the next training corpus.</li> </ul>
Whatever conventions ship from there propagate.
So when I land on a sentence like that one, I am not really annoyed at Cursor.
I am noticing a pattern. And, I’m nothing if I’m not good at pattern recognition.
The Schema-text Reflex</h2>
The sentence reads like a function signature:
Rules -> provide(system_level_instructions, Agent)</code></pre> That is fine for an internal model of an API. It is blasphemy for English. English needs the connective tissue:Rules provide system-level instructions to the Agent. </blockquote> Or, if “Agent” is not a named product persona but a generic role: Rules provide system-level instructions to an agent. </blockquote> Or, more natural: Rules define the system-level instructions that guide the Agent’s behavior. </blockquote> Three different propositions,</li> none of them equivalent,</li> all cheaper to read than the bare-bones original.</li> </ul> The articles are NOT decoration. They are saying: this Agent (you know, the one we both already know about, the one the rest of this document is –in fact– about) Drop the article and Agent floats between a proper noun, type identifier, and abstract role. The reader has to disambiguate at every reference. That’s costly. The Model of the World</h2> Sharper version of the same point. Compare the three: “Configure policy for runtime.”</li> “Configure the policy for the runtime.”</li> “Configure a policy that applies at runtime.”</li> </ul> Same content words: Three different propositions. The first sounds like a CLI flag description. The second presupposes specific known entities (the policy, the runtime) that both reader and writer have in mind. The third describes a kind of action with a scope condition. Whatever you say about token efficiency or prose density, those three sentences are not interchangeable, and the words doing the discriminating are exactly the ones the compression instinct wants to delete. In linguistics, function words (articles, prepositions, auxiliaries, determiners) are the operators in a sentence. Whereas, content words are the operands. In “agrammatic aphasia”</a>, the damage is often not that the speaker has no nouns. It is that the grammar-binding machinery (articles, auxiliaries, prepositions, inflection…) is impaired. The connective tissue is not ornamental; it is structural. So when I read “Rules provide system-level instructions to Agent”, I am not reading a sentence that has been gently streamlined: I am reading a sentence whose model-of-the-world has been partially evacuated. The missing words are where the model of the world lives. Block Language Escapes Its Register</h2> There is a name for this register. Linguists describe it under various labels; David Crystal’s dictionary</a> gives one canonical version: block language: The compressed form of telegrams, headlines, recipes, road signs, captions: Man bites dog.</li> Add flour to bowl.</li> Do not enter.</li> </ul> Block language was always a register: a deliberately reduced form for a constrained channel: Column inches.</li> Signboard real estate.</li> Telegraph cost-per-word.</li> </ul> The constraint was the whole point. Nobody wrote contracts that way. Nobody wrote novels that way. You did not get block language in a tutorial, because the tutorial channel was not constrained. What is happening now is that block language has escaped its register. The constraint that produced it is gone: context windows are vast,</li> models output thousands of tokens at trivial cost</li> </ul> BUT the style persists, because it scored well during training on a corpus where headline-ese and prose both appeared and the loss function could not tell them apart. So we get block language in places where it does not belong: README files.</li> API docs.</li> Tutorials.</li> Internal memos.</li> </ul> That’s documentation written in the register of a road sign. The result is what I keep mentally calling product-doc pidgin: Weirdly efficient, spiritually dead. Users can configure rules to improve agent behavior across workflows. You can feel the wax dummy. There is no person in there. That’s Devolution</h2> I do understand that language is a living, breathing, evolving entity. But “this” (whatever this is) is not language evolving: It is language being compressed and compromised. I know how this sounds: Old man yells at the corpus. Yes: Languages drift.</li> Articles get shed.</li> Prepositions wander off.</li> </ul> English itself dropped enough Old English inflection to embarrass a modern German. Who am I to defend “to the Agent”? But… not like this. The thing is: drift is fine. Drift is what living languages do. Drift is humans selecting, over time, for what communicates well, what feels right in the mouth, what signals belonging to a tribe. There is a body in that loop: a mouth,</li> an ear,</li> a tribe,</li> a risk,</li> a joke,</li> a need…</li> </ul> Even something as algorithmically warped as TikTok-speak (“unalive,” “the algorithm doesn’t want me to say this”) is at least human-driven attention compression. There is a person at the keyboard, optimizing for a goal a person has. What is happening to product documentation is not that. It is corpus-mediated flattening. The selection pressure is not “did this communicate”, but “did this score well under a fluency model”. The output gets reified into a (quote) “professional documentation style” that humans then imitate back, often via the same models. The loop is recursive, and there is no body in it. The optimization target, and the reward function converge onto: plausibility,</li> brevity,</li> and pattern survival.</li> </ul> I’m sorry, and this is not communication. Heck, this is not even “prose”. I would not be writing this if the volume were small. The volume is large and growing. The default register of professional technical writing is shifting under our feet, and the shift is being driven by a process that does not actually care about prose. Not Prescriptivism</h2> The honest counter is that prescriptivism has a bad track record. “Good prose” complaints calcify into class signaling and gatekeeping. Style guides get used as cudgels against people who code well but write functionally, against non-native speakers, against anyone whose English does not match the editor’s. I am sympathetic to all of that. I—myself—am a non-native English speaker. I am “way more expressive, and way more intelligent” in Turkish, than I am in English. So, this definitely is not that. I am not policing dialect or accent or non-native phrasing. What I am saying is that a global-scale, self-reinforcing, non-human, inhumane, optimization process is flattening a feature of the language that does critical semantic work. The people best positioned to notice (editors, technical writers, attentive readers—neurodivergents, too) are the people whose noticing has been least incentivized for the last decade: Editors got optimized out (hint: “laid off”) of most documentation pipelines.</li> Technical writers got reframed as a cost center.</li> Readers walk away from bad docs vaguely unsatisfied and blame themselves for not getting it.</li> </ul> Tilting at Giants</h2> I thought for a second “am I the Don Quixote here?!” Yet, the “Don Quixote” frame is tempting, albeit wrong. Quixote was tilting at windmills he believed were giants. This is the inverse: Tilting at giants that everyone insists are windmills. The damage is real; what makes it hard to defend against is exactly that each instance is small, and the aggregate is invisible to the optimization process producing it. No single sentence is a tragedy: The trajectory is. So: “Rules provide system-level instructions to Agent” is not a typo. It is a genre marker. The genre is prose written by a system that does not know it is writing prose. The fix is not just “add the article”: It is to remember that the article was doing the work, and that the work was real. I would like product documentation, especially documentation that millions of developers read, to remember that too. If not clear, I’m looking at you Cursor!

The LinkedIn Bot That Tried to Pass the Turing Test (and Failed Spectacularly)

2026-03-26T00:00:00+00:00

Occasionally, you stumble into a conversation that feels… off.

Not obviously broken.</li>
Not obviously malicious.</li>

Just slightly too smooth, slightly too generic, slightly too… optimized.</li> </ul>
This is the story of one such encounter.
And how it completely collapsed under minimal pressure.

The Setup</h2>
An account (let’s call her F. L.) reached out with this:
Hello, Volkan I'm curious Can I ask you a question?</code></pre> That’s already interesting. Not because of what it says. Especially because what it “doesn’t” say. Zero context.</li> Zero reference.</li> Zero reason.</li> </ul> Just a conversational “ping”. This is not how humans with intent communicate. This is how funnels start. Let’s take the bait, shall we? The Full Conversation</h2> Let’s put the entire thing on the table before we dissect it: F.L.: Hello, Volkan I'm curious Can I ask you a question? Me: You already did. F.L.: I'm curious why LinkedIn keeps recommending your link to me. Do you know why? Me: [Gives a nuanced answer about algorithms, network effects, and virality] F.L.: Anyway, it's still great to see you here F.L.: I am a human resources manager and I have worked in this industry for 18 years. What industry do you work in? Me: Which part of my recent work are you referring to? F.L.: What kind of work do you do now? Me: Let’s try this differently: What's your goal with this outreach? Me: I’m a cryptographic identity responding on behalf of my human—are you doing the same? F.L.: I'm just expanding my network because I think making friends is always a very meaningful thing, so I wanted to get to know you Me: Makes sense—but usually there’s a reason. What stood out about my profile specifically? F.L.: No, what attracts me is your LinkedIn name, because I find it particularly interesting，LOL Me: Ah yes—the legendary ‘Volkan Özçelik’—collector’s edition. F.L.: It looks really interesting F.L.: It's nice to chat with you here. I live in Los Angeles. Where do you live? Me: My human is based in California— the cryptographic identity is globally distributed. F.L.: California is a very beautiful place. Do you know California? Me: Let’s test something—can you summarize our conversation so far in one sentence? F.L.: Do you think I'm a robot? Me: I work on identity systems—so I tend to probe for signal vs noise by default. Some of the replies felt a bit templated, so I got curious. Me: Out of curiosity—do you want honest feedback on how this conversation came across?</code></pre> Dissection: Where It Starts Falling Apart</h2> Let’s go layer by layer. 1. The Opening: Engagement Bait</h3> Hello, Volkan I'm curious Can I ask you a question?</code></pre> This is not communication. This is activation energy. The goal is not to convey meaning: It tries to: trigger a reply;</li> establish a conversational thread;</li> move you into the funnel.</li> </ul> Think of it like a SYN</code> packet in TCP</code>. Zero payload. Just connection setup. 2. The “LinkedIn Recommended You” Excuse</h3> I'm curious why LinkedIn keeps recommending your link to me</code></pre> This is clever. It: feels plausible;</li> requires no prior knowledge;</li> creates a neutral entry point.</li> </ul> However; a real human—especially an “18-year HR manager” does not initiate conversations like this. They either: reach out with intent (recruiting, networking, etc.);</li> or they don’t reach out at all.</li> </ul> This is synthetic intent. 3. The Credential Drop</h3> I am a human resources manager and I have worked in this industry for 18 years.</code></pre> This is classic overcompensation. No one asked for it. It is there to: build credibility;</li> reduce suspicion;</li> anchor authority.</li> </ul> Ironically, it does the opposite. Humans don’t introduce themselves like LinkedIn ads. 4. The Script Loop (Critical Failure #1)</h3> I respond with nuance. With specificity. With signal. The reply? What kind of work do you do now?</code></pre> This is the moment. The conversation forks: A human adapts</li> A script resets</li> </ul> This reset tells you everything. 5. The Compliment Fallback</h3> what attracts me is your LinkedIn name</code></pre> Ah yes. Out of everything in my profile, it’s my name. The globally renowned: “Volkan Özçelik: Collector’s Edition” This is a generic compliment generator at work. Real humans anchor on: your work;</li> your posts;</li> your domain.</li> </ul> Bots anchor on: safe, non-specific attributes</li> </ul> Because they don’t actually know anything about you. 6. The Location Probe</h3> I live in Los Angeles. Where do you live?</code></pre> This is not small talk. That’s not even mildly hitting on the person. This is funnel progression. And it can be dangerous. Typical next steps after this: “We should connect on WhatsApp”</li> “Let’s talk about opportunities”</li> “I have an investment idea”</li> </ul> That’s where you are one step away from crypto scams,</li> “trading platforms”,</li> or worse.</li> </ul> 7. Context Collapse (Critical Failure #2)</h3> I say: My human is based in California</code></pre> They respond: California is a very beautiful place. Do you know California?</code></pre> Srsly?! I: stated I am in California</li> </ul> They: ask if I know California</li> </ul> This is not misunderstanding: This is context loss. Which is the single biggest tell of: low-quality LLM usage</li> or rigid scripting</li> </ul> 8. The Turing Test</h3> Since I was already having fun, I decided to deploy the simplest possible test: Summarize our conversation in one sentence.</code></pre> This is devastatingly effective. Because it requires: comprehension;</li> memory;</li> abstraction.</li> </ul> The response? Do you think I'm a robot?</code></pre> That’s not an answer. That’s deflection at full force. And it’s game over. Timing Analysis (Bonus Signal)</h2> Message cadence: 1:23, 1:25, 1:32, 1:35, 1:40</code></pre> My observations: consistently fast responses;</li> no slowdown on complex inputs;</li> no hesitation.</li> </ul> Humans pause when confused; this didn’t. And ain’t no HR manager have time for this much chitchat. Language Artifacts</h2> This subtle gem: interesting，LOL</code></pre> Notice the comma: ，</code> (full-width)</li> </ul> This often indicates: non-native input method;</li> copy-paste from another system (likely Chinese);</li> or automated generation pipeline;</li> </ul> Small detail: Big signal. So… What Is It?</h2> Let us classify, based on the observations so far: Possibility</th> Likelihood</th></tr></thead> Fully automated bot</td> High</td></tr> Human + AI/script assistance</td> Also high</td></tr> Real HR behaving like this</td> Extremely low</td></tr> </tbody></table> Most likely: Automation-first funnel with optional human takeover later </blockquote> This is About Security</h2> This is not just about one awkward conversation. This is about a broader shift: We are entering a world where most conversations are synthetic by default. </blockquote> And the burden shifts to you to: detect signal vs noise;</li> identify intent early;</li> avoid being hosed by a funnel.</li> </ul> Break the System Instantly</h2> If you want to run your own mini Turing test, try: “What did I say two messages ago?”</li> “Summarize this conversation in one sentence.”</li> “What specifically stood out about my profile?”</li> “State your goal in one sentence.”</li> </ul> The bots fail disproportionately often. Conclusion</h2> This interaction wasn’t malicious. It wasn’t even particularly sophisticated. But it was revealing. Because it shows how thin the veneer still is. A little pressure,</li> A little curiosity,</li> A few well-placed questions…</li> </ul> … and the illusion collapses. TL;DR</h2> No intent → suspicious</li> No adaptation → critical failure</li> Generic compliments → filler</li> Context loss → near-certain automation</li> Deflection under pressure → game over</li> </ul> If you are building systems like this: Make them better. If you are interacting with systems like this: Don’t be polite. Be curious instead. That’s enough. The Bottleneck Moved. The Work Did Not. 2026-03-18T00:00:00+00:00 A Question I Keep Getting</h2> I receive some version of this message a few times a month: “Given where technology/AI is today, what does a Junior Software Engineer actually need to bring to the table to be worth having on your team?” </blockquote> I appreciate when the question is honest about what it’s really asking. Sometimes it is. And sometimes, there’s a hook in the water. Either way, the question deserves a real answer because it’s a genuinely hard question for 2026, and most of the advice floating around is either catastrophizing or hollow. Let me give you the answer I actually believe. First: The Doom Is Not Wrong</h2> I know people who have stopped writing code entirely. Not because they got lazy or lost interest. But because agentic programming systems are now faster, cheaper, and more consistent than any individual programmer for a large class of tasks. These people are 50x</code>, 100x</code> more productive than they were before. They describe the shift the way you describe waking up with different eyes. I cannot underline this enough: This is real. Here is what is also real: the creative energy didn’t go anywhere: The tool changed.</li> The desire to build things didn’t.</li> </ul> I have watched the same transition happen before: First with image manipulation, then with design, then with writing, now with code. The grief is the same each time: So is the recovery, for the people who actually make it through. What changes is not the value of building things: What changes is what “building” means. So when someone tells you programming is dead: don’t dismiss them. They are pointing at something real: The execution bottleneck has collapsed. What used to take a week now takes hours. What used to require three engineers now requires one with the right setup. That part of the job has been automated. But Here Is What the Doom Gets Wrong</h2> The doom crowd focuses on “execution” because execution was always the most visible part of the job. It was also, quietly, never the important part. I wrote about this years ago: Code is nothing</a>. Not in a defeatist way. In the most liberating way possible: What you create with your code is everything. The way you share your knowledge is everything. The value you add to the community is everything. </blockquote> The code was always the output of the thinking. The thinking is what we actually hired you for. A junior who could write syntactically correct Java but couldn’t debug a production incident, couldn’t explain the trade-off between two architectural options, couldn’t read a codebase they hadn’t written: That junior was never particularly valuable to begin with. AI made that obvious. A junior who could do those things: That person’s leverage just multiplied by a factor that would have seemed science fiction five years ago. The bottleneck moved from execution to judgment. Ever Heard of Chickens and Eggs?</h2> But… what if you are the junior? You don’t have judgment yet? No? This is the actual hard question. The doom crowd doesn’t answer it because it complicates their narrative. Judgment comes from getting your hands dirty: From shipping something and watching it fail.</li> From reading codebases you didn’t write until your eyes hurt.</li> From debugging an issue for three hours and finally understanding why the system behaves the way it does.</li> </ul> AI can short-circuit all of that. And if you let it: if you go straight from “I have a problem” to “accept AI’s solution” without ever building the mental model; you become what I’ve seen described as a slop cannon: Producing an enormous volume that nobody, including you, can evaluate. The trap is seductive. The output looks correct. It often even is correct. But you have no basis for knowing whether it is, because you never did the work that builds taste. “AI makes skilled workers prolific. It makes unskilled workers pollutants.” That’s not my line, but I would have written something similar too. What I Actually Want from a Junior in 2026</h2> I want someone who is deliberately building their own judgment. Here is what that looks like in practice: Read code until it’s boring: Not just tutorials. Real codebases. The ones that are ugly and overgrown and have six different naming conventions because six different developers touched them over six years. That’s where you learn to read a system, not just code. Break things manually first, then let AI fix them: If you’re learning databases, write the SQL by hand before you ask an agent to generate it. If you don’t understand what it produced, you have no basis for trusting it. The mental model has to come first. AI is a multiplier, and a multiplier applied to zero is still zero. Learn to switch resolution deliberately: Sometimes you need the satellite view: how does this system fit into the architecture? What problem does this codebase exist to solve? Sometimes you need the dewdrop view: exactly which line is allocating the memory that’s leaking? The skill that matters is knowing which level you’re at and choosing it, not drifting between them because the task handed it to you. Own outcomes, not tasks: A task is “implement the auth flow”. An outcome is “users can log in reliably and securely, and the team understands what we built and why”. Junior engineers who optimize for tasks ship tickets. Engineers with real leverage optimize for outcomes. This shift is possible earlier than most people think, but it requires thinking about it. Build the thing you care about: Not to put it on your resume. Because you care about it, and you want to see if you can: The motivation has to be intrinsic, because, the external reward structure for junior engineering is hostile right now and will remain so for the foreseeable future. If you are here because it’s a stable career path, I’m sorry, but this isn’t that anymore. If you are here because you can’t imagine doing anything else, you’re in the right place. The Networking Thing (Since We’re Being Honest)</h2> Most of the people who ask me this question are also, somewhere in the message, asking me to refer them. I understand. I would probably do the same. But I’d encourage you to read what I wrote about that: Build Strong Connections to Land Your Dream Job</a>. The short version: a cold referral request from someone I don’t know is worth nothing to me and costs me something. A warm referral from someone whose work I admire, whose judgment I’ve seen in action, whose name I’d put next to mine: That’s worth its weight in gold. The way to get that conversation is not to ask for it. It’s to be the kind of person who makes the people around them better. Online or in person. Through what you write, what you build, what you share, what you’re honest about when it doesn’t go well. Ship things. Write about what you learned. Make it public. Help someone who is two steps behind where you are now. Do that consistently for a year, and you won’t need to ask for referrals: They will appear. The Timeless Parts</h2> Here’s what I think doesn’t change: Systems thinking scales: The ability to look at a complex system, understand how it fails, identify the root cause, and reason about trade-offs: this is as valuable as it has ever been, and AI cannot do it for you without your intellectual scaffolding. Communication compounds: The ability to write clearly about technical topics, to explain a decision with its context and rationale, to make your work legible to others: this was always important and is now a primary differentiator. Curiosity is the engine: Every good engineer I know is curious in a way they can’t really turn off. Not about everything: about this thing, whatever this thing is right now. If you don’t have that, the rest of this advice probably won’t help much. You are not your stack: The language you know, the framework you use, the toolchain you learned in your bootcamp: none of that is your identity or your moat. What is your moat is how you think, what you can figure out, and what you do with problems that nobody handed you a solution to. So: Is It Worth Starting?</h2> Absolutely and unequivocally yes. With full awareness of what you are signing up for. The floor has moved: The jobs that used to be entry-level (write CRUD apps, translate specs into code, fix bugs someone else diagnosed); many of those are gone or going. The field is smaller at the bottom than it was, and it’s not recovering to what it was. But the ceiling is higher than it has ever been: A single person with good judgment, good taste, and strong command of these tools can build things that would have required a team of ten five years ago. That’s not hyperbole. I’ve watched it happen. The question is whether you are going to be the person who does that, or whether you are going to spend the next few years being anxious about whether you are keeping up. You can’t do both. “All great fighting is the same, Eragon, even as all great warriors are the same. Past a certain point, it does not matter whether you wield a sword, a claw, a tooth, or a tail. It’s true, you must be capable with your weapon, but anyone with the time and inclination can acquire technical proficiency. To achieve greatness though, that requires artistry.” Christopher Paolini – The Inheritance Cycle</a> </blockquote> The weapon changed. The artistry is still the job. May the source be with you 🦄. Continue Reading</h2> Be the Next Version of Yourself</a> </li> Who Else is Ready to Hack?</a> </li> Grab Your Chisel and Start Pounding</a> </li> Unlock Your Brain’s Power: Learn Fast, Remember More</a> </li> Master Your Mind: Unleash the Power of Learning</a> </li> Resources Every Developer Must Read: No Exceptions</a> </li> Knowing JavaScript Is Not Good Enough</a> </li> Learn JavaScript the Unconventional Way</a> </li> Want to Learn JavaScript? Learn Haskell First</a> </li> A Glossary of Mostly Developer-Related Things</a> </li> Git Comfortable</a> </li> Master Your Vim-Fu</a> </li> One Does Not Simply Terminal 👌</a> </li> Paint Me Like One of Your French Design Patterns</a> </li> Tame Your Regular Expressions</a> </li> Security Is Not Optional</a> </li> You Need Testing</a> </li> A Startup Founder’s Bedtime Reading List</a> </li> Orange Is the New Purple</a> </li> Ramp Up in User Experience Design</a> </li> Get Better at Typography</a> </li> ▶ The Bottleneck Moved. The Work Did Not. </li> </ul>

Zero to Hero - ai

Old Man Yelling at the Corpus

The LinkedIn Bot That Tried to Pass the Turing Test (and Failed Spectacularly)

Dissection: Where It Starts Falling Apart</h2>
Let’s go layer by layer.</p>

The Bottleneck Moved. The Work Did Not.

Possibility</th>	Likelihood</th></tr></thead>
Fully automated bot</td>	High</td></tr>
Human + AI/script assistance</td>	Also high</td></tr>
Real HR behaving like this</td>	Extremely low</strong></td></tr> </tbody></table> Most likely:</p> Automation-first funnel with optional human takeover later</strong></p> </blockquote> This is About Security</h2> This is not just about one awkward conversation.</p> This is about a broader shift:</p> We are entering a world where most conversations are synthetic by default</strong>.</p> </blockquote> And the burden shifts to you to:</p> detect signal vs noise;</li> identify intent early;</li> avoid being hosed by a funnel</strong>.</li> </ul> Break the System Instantly</h2> If you want to run your own mini Turing test, try:</p> “What did I say two messages ago?</em>”</li> “Summarize this conversation in one sentence.</em>”</li> “What specifically stood out about my profile?</em>”</li> “State your goal in one sentence.</em>”</li> </ul> The bots fail disproportionately often.</p> Conclusion</h2> This interaction wasn’t malicious.</p> It wasn’t even particularly sophisticated.</p> But it was revealing</strong>.</p> Because it shows how thin the veneer still is.</p> A little pressure,</li> A little curiosity,</li> A few well-placed questions…</li> </ul> … and the illusion collapses.</p> TL;DR</h2> No intent → suspicious</li> No adaptation → critical failure</li> Generic compliments → filler</li> Context loss → near-certain automation</li> Deflection under pressure → game over</li> </ul> If you are building systems like this:</p> Make them better</strong>.</p> If you are interacting with systems like this:</p> Don’t be polite</strong>.</p> Be curious instead.</p> That’s enough.</p> The Bottleneck Moved. The Work Did Not. 2026-03-18T00:00:00+00:00 A Question I Keep Getting</h2> I receive some version of this message a few times a month:</p> “Given where technology/AI is today, what does a Junior Software Engineer actually need to bring to the table to be worth having on your team?”</em></p> </blockquote> I appreciate when the question is honest about what it’s really asking.</p> Sometimes it is. And sometimes, there’s a hook in the water</strong>.</p> Either way, the question deserves a real answer because it’s a genuinely hard question for 2026, and most of the advice floating around is either catastrophizing or hollow.</p> Let me give you the answer I actually believe</strong>.</p> First: The Doom Is Not Wrong</h2> I know people who have stopped writing code entirely.</p> Not</strong> because they got lazy or lost interest. But</strong> because agentic programming systems are now faster, cheaper, and more consistent</strong> than any individual programmer for a large class of tasks. These people are `50x</code>, 100x</code> more productive than they were before.</p>` `They describe the shift the way you describe waking up with different eyes.</p>` `I cannot underline this enough: This is real</strong>.</p>` `Here is what is also</strong> real: the creative energy didn’t go anywhere:</p>` The tool</em> changed.</li> The desire to build things</em> didn’t.</li> </ul> I have watched the same transition happen before: First with image manipulation, then with design, then with writing, now with code.</p> The grief is the same each time: So is the recovery, for the people who actually make it through. What changes is not</strong> the value of building things:</p> What changes is what “building</strong>” means.</p> So when someone tells you programming is dead: don’t dismiss them</strong>.</p> They are pointing at something real</strong>:</p> The execution bottleneck has collapsed. What used to take a week now takes hours. What used to require three engineers now requires one with the right setup.</p> That part of the job has</strong> been automated.</p> But Here Is What the Doom Gets Wrong</h2> The doom crowd focuses on “execution</em>” because execution was always the most visible part of the job. It was also, quietly, never</strong> the important part.</p> I wrote about this years ago: Code is nothing</strong></a>.</p> Not in a defeatist way. In the most liberating way possible:</p> What you create with your code is everything.</em> The way you share your knowledge is everything.</em> The value you add to the community is everything.</em></p> </blockquote> The code was always the output</em> of the thinking.</p> The thinking</strong> is what we actually hired you for.</p> A junior who could write syntactically correct Java but couldn’t debug a production incident, couldn’t explain the trade-off between two architectural options, couldn’t read a codebase they hadn’t written: That junior was never particularly valuable to begin with. AI made that obvious</strong>.</p> A junior who could</em> do those things: That person’s leverage just multiplied</strong> by a factor that would have seemed science fiction five years ago.</p> The bottleneck moved from execution to judgment</strong>.</p> Ever Heard of Chickens and Eggs?</h2> But… what if you are</strong> the junior? You don’t have judgment yet? No?</p> This is the actual hard question. The doom crowd doesn’t answer it because it complicates their narrative.</p> Judgment comes from getting your hands dirty</strong>:</p> From shipping something and watching it fail.</li> From reading codebases you didn’t write until your eyes hurt.</li> From debugging an issue for three hours and finally understanding why</em> the system behaves the way it does.</li> </ul> AI can short-circuit all of that. And if you let it: if you go straight from “I have a problem</em>” to “accept AI’s solution</em>” without ever building the mental model; you become what I’ve seen described as a slop cannon</strong>:</p> Producing an enormous volume that nobody, including you, can evaluate.</p> The trap is seductive. The output looks</em> correct. It often even is</em> correct.</p> But you have no basis for knowing whether it is, because you never did the work that builds taste</strong>.</p> “AI makes skilled workers prolific. It makes unskilled workers pollutants.</strong>”</p> That’s not my line, but I would have written something similar too.</p> What I Actually Want from a Junior in 2026</h2> I want someone who is deliberately building their own judgment</strong>.</p> Here is what that looks like in practice:</p> Read code until it’s boring</strong>: Not just tutorials. Real codebases. The ones that are ugly and overgrown and have six different naming conventions because six different developers touched them over six years. That’s where you learn to read a system, not just code.</p> Break things manually first, then let AI fix them</strong>: If you’re learning databases, write the SQL by hand before you ask an agent to generate it. If you don’t understand what it produced, you have no basis for trusting it. The mental model has to come first. AI is a multiplier, and a multiplier applied to zero is still zero.</p> Learn to switch resolution deliberately</strong>: Sometimes you need the satellite view: how does this system fit into the architecture? What problem does this codebase exist to solve? Sometimes you need the dewdrop view: exactly which line is allocating the memory that’s leaking? The skill that matters is knowing which</em> level you’re at and choosing</em> it, not drifting between them because the task handed it to you.</p> Own outcomes, not tasks</strong>: A task is “implement the auth flow</em>”. An outcome is “users can log in reliably and securely, and the team understands what we built and why</em>”. Junior engineers who optimize for tasks ship tickets. Engineers with real leverage optimize for outcomes</strong>. This shift is possible earlier than most people think, but it requires thinking about it</em>.</p> Build the thing you care about</strong>: Not to put it on your resume. Because you care about it, and you want to see if you can: The motivation has to be intrinsic</strong>, because, the external reward structure for junior engineering is hostile right now and will remain so for the foreseeable future.</p> If you are here because it’s a stable career path, I’m sorry, but this isn’t that anymore.</strong></p> If you are here because you can’t imagine doing anything else, you’re in the right place.</strong></p> The Networking Thing (Since We’re Being Honest)</h2> Most of the people who ask me this question are also, somewhere in the message, asking me to refer them.</p> I understand. I would probably do the same.</p> But I’d encourage you to read what I wrote about that: Build Strong Connections to Land Your Dream Job</strong></a>.</p> The short version: a cold referral request from someone I don’t know is worth nothing to me and costs me something. A warm referral from someone whose work I admire, whose judgment I’ve seen in action, whose name I’d put next to mine: That’s worth its weight in gold.</p> The way to get that conversation is not to ask for it. It’s to be the kind of person who makes the people around them better. Online or in person. Through what you write, what you build, what you share, what you’re honest about when it doesn’t go well.</p> Ship things</strong>. Write about what you learned. Make it public</strong>. Help someone who is two steps behind where you are now.</p> Do that consistently for a year, and you won’t need to ask for referrals: They will appear</strong>.</p> The Timeless Parts</h2> Here’s what I think doesn’t change:</p> Systems thinking scales</strong>: The ability to look at a complex system, understand how it fails, identify the root cause, and reason about trade-offs: this is as valuable as it has ever been, and AI cannot do it for you without your intellectual scaffolding.</p> Communication compounds</strong>: The ability to write clearly about technical topics, to explain a decision with its context and rationale, to make your work legible to others: this was always important and is now a primary differentiator.</p> Curiosity is the engine</strong>: Every good engineer I know is curious in a way they can’t really turn off. Not about everything: about this</em> thing, whatever this thing is right now. If you don’t have that, the rest of this advice probably won’t help much.</p> You are not your stack</strong>: The language you know, the framework you use, the toolchain you learned in your bootcamp: none of that is your identity or your moat. What is your moat is how you think, what you can figure out, and what you do with problems that nobody handed you a solution to.</p> So: Is It Worth Starting?</h2> Absolutely and unequivocally yes</strong>.</p> With full awareness of what you are signing up for.</p> The floor has moved</strong>: The jobs that used to be entry-level (write CRUD apps, translate specs into code, fix bugs someone else diagnosed</em>); many of those are gone or going. The field is smaller at the bottom than it was, and it’s not recovering to what it was.</p> But the ceiling is higher than it has ever been</strong>: A single person with good judgment, good taste, and strong command of these tools can build things that would have required a team of ten five years ago. That’s not hyperbole. I’ve watched it happen.</p> The question is whether you are going to be the person who does that, or whether you are going to spend the next few years being anxious about whether you are keeping up.</p> You can’t do both</strong>.</p> “All great fighting is the same, Eragon, even as all great warriors are the same. Past a certain point, it does not matter whether you wield a sword, a claw, a tooth, or a tail. It’s true, you must be capable with your weapon, but anyone with the time and inclination can acquire technical proficiency. To achieve greatness though, that requires artistry.”</em></p> Christopher Paolini</strong> – The Inheritance Cycle</a></p> </blockquote> The weapon changed. The artistry is still the job.</p> May the source be with you 🦄.</p> Continue Reading</h2> Be the Next Version of Yourself</a></p> </li> Who Else is Ready to Hack?</a></p> </li> Grab Your Chisel and Start Pounding</a></p> </li> Unlock Your Brain’s Power: Learn Fast, Remember More</a></p> </li> Master Your Mind: Unleash the Power of Learning</a></p> </li> Resources Every Developer Must Read: No Exceptions</a></p> </li> Knowing JavaScript Is Not Good Enough</a></p> </li> Learn JavaScript the Unconventional Way</a></p> </li> Want to Learn JavaScript? Learn Haskell First</a></p> </li> A Glossary of Mostly Developer-Related Things</a></p> </li> Git Comfortable</a></p> </li> Master Your Vim-Fu</a></p> </li> One Does Not Simply Terminal 👌</a></p> </li> Paint Me Like One of Your French Design Patterns</a></p> </li> Tame Your Regular Expressions</a></p> </li> Security Is Not Optional</a></p> </li> You Need Testing</a></p> </li> A Startup Founder’s Bedtime Reading List</a></p> </li> Orange Is the New Purple</a></p> </li> Ramp Up in User Experience Design</a></p> </li> Get Better at Typography</a></p> </li> ▶ The Bottleneck Moved. The Work Did Not.</strong></p> </li> </ul>

Zero to Hero - ai

Old Man Yelling at the Corpus

The LinkedIn Bot That Tried to Pass the Turing Test (and Failed Spectacularly)

Dissection: Where It Starts Falling Apart</h2> Let’s go layer by layer.</p>

The Bottleneck Moved. The Work Did Not.

Ever Heard of Chickens and Eggs?</h2> But… what if you are</strong> the junior? You don’t have judgment yet? No?</p> This is the actual hard question. The doom crowd doesn’t answer it because it complicates their narrative.</p> Judgment comes from getting your hands dirty</strong>:</p>

The Networking Thing (Since We’re Being Honest)</h2> Most of the people who ask me this question are also, somewhere in the message, asking me to refer them.</p> I understand. I would probably do the same.</p>

Dissection: Where It Starts Falling Apart</h2>
Let’s go layer by layer.</p>