Before AI, we wrote code. After AI, we write instructions for the AI to write code. Congratulations. You are now a prompt farmer.
There is a moment every developer hits these days. You open your editor. You stare at the blank file. And instead of typing a function, you type:
“Create a Laravel service class that handles payment processing with Stripe, includes retry logic, logs all transactions and follows SOLID principles.”
Then you press Enter.
Then the AI writes 200 lines of clean, documented, well-structured code.
Then you read it, nod like you understand it and push it to production.
You did not write a single line of PHP. But somehow your Git commit says “feat: add payment service.” Sure. Let’s go with that.
The Job Title Stayed. The Job Description Did Not.
Ten years ago, a software engineer wrote software. Wild concept, I know.
Today, a software engineer writes a paragraph describing software, watches an AI generate the software, reviews the software like a sleepy senior dev at 4pm on a Friday and merges it.
We used to joke that our job was basically googling things. Now our job is basically asking a very expensive chatbot things. The google at least made us read the StackOverflow answer. The AI just… hands it to us. Warm. Ready. Slightly wrong in a way that only shows up three weeks later in production.
We went from engineers to editors. And honestly? The pay is the same so nobody is complaining out loud.
Markdown Is the New Code
Here is what a senior developer’s day looks like in 2026.
8:30am — Open Claude Code. Write a CLAUDE.md file explaining how the project works.
9:00am — Open a new chat. Paste context. Write more markdown.
10:00am — Realize the AI misunderstood. Write more markdown to correct it.
11:00am — Create a .cursorrules file. Which is also markdown. Explaining the rules. In markdown.
12:00pm — Lunch.
1:00pm — Review AI-generated code. Leave comments. In markdown.
3:00pm — Update the README. Markdown.
5:00pm — Write the PR description. Markdown.
At no point today did this person write a for loop. But they wrote approximately 4,000 words of markdown. In a job titled "Software Engineer."
Somewhere a computer science professor is having a very confusing existential crisis.
The Irony That Will Make You Uncomfortable
Let me tell you about the old world.
In the old world, you would finish a feature, open a Jira ticket, mark it Done and immediately close the laptop before anyone asked you to document it. Documentation was the enemy. Documentation was what you promised to do and never did. Documentation was the thing the next developer cursed you for six months later.
“Why is there no README?” “Why is this function called processStuff?" "What does this env variable even do?"We did not know. The developer who wrote it did not leave notes. The developer who wrote it is now in a different company. The developer who wrote it is the reason you are debugging this at 11pm.
We hated documentation the way cats hate baths. Instinctively. Completely. Without apology.
And now?
Now we write CLAUDE.md. We write AGENTS.md. We write CONTEXT.md. We write system prompts that are longer than some of our actual features. We document everything because if we do not, the AI will make something up and it will be technically correct but completely wrong for our specific use case.
We became documentation writers. Not because we matured. Not because we suddenly care about future developers. But because the AI needs to be told what to do in plain English and if we are vague about it, it will confidently build the wrong thing.
Survival changed us. Not principles.
The Markdown Hierarchy Nobody Talks About
There is now an unspoken class system in development teams.
Junior developer: Writes code. Still types actual syntax. Occasionally proud of it.
Mid-level developer: Writes prompts to generate code. Edits the output. Calls it a review.
Senior developer: Writes markdown files that tell the AI how to write prompts that generate code. Has not touched a keyboard for anything other than markdown in two months.
Technical Lead: Writes architecture documents in markdown. Attaches them to the AI context. Watches the AI design the whole system. Presents it to the client as “our approach.”
CTO: Has a Notion page. It is also markdown. The AI reads it and runs the company.
We climbed the career ladder and at the top there was just a very nice text editor and a blinking cursor waiting for us to explain ourselves.
CLAUDE.md Is Basically Hiring Onboarding But Worse
Think about what we put in CLAUDE.md.
Project overview. Tech stack. Coding standards. What to avoid. What to always do. How to name things. How to structure folders. Which packages we use. Which packages we banned after that one incident.
This is an onboarding document. We spent years complaining that nobody reads onboarding documents. We refused to write them. We let new hires figure it out by reading the code and asking the guy sitting next to them.
Now we write a more detailed version of that same onboarding document. Except the new hire is an AI that actually reads it every single time without complaining, without skipping to the end and without asking “is there a shorter version of this.”
The AI is a better new hire than most humans we interviewed. It shows up on time, reads the docs and does not negotiate salary. It also hallucinates sometimes. But honestly so do some of our developers after enough coffee.
What We Actually Learned
Here is the thing nobody wants to say out loud.
The developers who are thriving right now are not the ones who write the best code. They are the ones who explain things the best. The ones who can describe a problem clearly, give enough context, anticipate what could go wrong and communicate intent precisely.
Which is exactly what good documentation has always been.
We spent twenty years saying “the code is the documentation.” We were wrong and too proud to admit it. The AI came along and said “cool, show me the code” and then built something completely different from what we intended because there was no context, no explanation and no structure to follow.
Turns out communication was the skill all along. We just refused to practice it because we thought typing semicolons was the hard part.
Surprise. The semicolons were never the hard part.
The AI Limit Is the New 5pm
There is a meme that has been quietly circulating in developer circles on X and Reddit. It goes something like this:
“My working hours are from when Claude resets to when Claude hits the limit.”
And the scary part? People are not joking.
We have replaced the concept of a workday with an AI usage cycle. Before, you knew you were done when your brain stopped working. Now you know you are done when the little message appears saying “You’ve reached your usage limit. Come back in 5 hours.”
That is your clock-out notification. That is your sign from the universe. That is the AI version of your manager saying “okay team, wrap it up.”
Some developers have genuinely restructured their schedule around the reset timer. They wake up early to catch the fresh limit. They sprint through the most complex features while the AI is fresh and unrestricted. They save the easy stuff, the CSS tweaks and the config files, for when the model is running on fumes and giving shorter responses. They have optimized their entire productivity system around a token budget.
This is either brilliant time management or the most elaborate way to admit you cannot work without a machine holding your hand. Possibly both.
The real comedy is what happens when the limit hits mid-feature. You are deep in it. The architecture is half built. The AI has context on seventeen files and three different approaches you tried and rejected. And then. Nothing. “You’ve reached your limit.”
You stare at the screen. You stare at the half-built feature. You open a new chat. You spend fifteen minutes re-explaining everything to a Claude that has never met you before and has no memory of your past forty messages.
It is like firing your best contractor mid-project and replacing them with their identical twin who knows nothing about the job. Every single day.
And still, developers prefer this to writing the code themselves. That should tell you something about how bad writing the code ourselves had become.
The New Competitive Advantage Is Something We Cannot Put on a Resume
Here is the part that should worry you.
The AI does not care how fast you type. It does not care that you memorized the entire Laravel documentation. It does not care that you can write a recursive function in your sleep or that you know the difference between array_map and array_walk without googling it.
The AI cares about one thing. How well you can imagine.
Because here is what actually happens when two developers sit in front of the same AI tool. Developer A types “create a user authentication system.” Gets a generic login page. Nods. Ships it. Developer B sits there for ten minutes first. Thinks about the user. Thinks about edge cases nobody mentioned. Thinks about what the feature needs to feel like, not just what it needs to do. Then writes a prompt so specific, so layered, so full of intent that the AI produces something that feels like it was designed by someone who actually cared.
Same tool. Same model. Completely different output.
The separator was not skill. It was imagination.
The developer who wins in this era is not the one who knows the most syntax. It is the one who can close their eyes, picture something that does not exist yet and describe it clearly enough that the AI can build it. They are not coding. They are architecting in their mind first and then narrating it into existence.
That sounds poetic. It is also slightly terrifying.
Because imagination is not something you can learn in a bootcamp. There is no course called “Creative Vision for Backend Developers.” There is no certification for “Thinking Interesting Thoughts.” You either bring something original to the prompt or you get something generic back from the model.
Garbage in, garbage out has always been true. But now it is not about garbage data. It is about garbage imagination.
If you cannot picture what good looks like, the AI cannot either. It will give you something that works. Something that passes the tests. Something that a client will accept because they do not know what they were supposed to get.
But it will not be remarkable. It will be adequate. And adequate is what gets replaced first.
So if you are the kind of developer who has always relied on knowing things rather than imagining things, this is your gentle notice.
The knowledge gap between developers is closing fast. Everyone has access to the same models, the same tools, the same documentation fed into the same context window.
The imagination gap is still wide open.
And if you are not creative enough to imagine what could be…
Well.
Let’s just say the AI will imagine it for someone else instead.
So What Are We Now
Honestly? I do not know.
We are something between a developer, a writer, a prompt engineer (a title that will age like milk but here we are) and a very anxious reviewer who is always slightly suspicious that the AI did something clever that we will not catch until it is someone else’s problem.
We write markdown. We write prompts. We write context files and system instructions and PR descriptions that are longer than the actual code changes.
And the code ships. And the clients are happy. And the invoices get paid.
Maybe the job was never really about the code. Maybe it was always about solving problems and the code was just the current tool for doing it.
Or maybe we are just markdown farmers now and the sooner we accept that the better.
Either way, I need to go update my CLAUDE.md. The AI keeps generating PSR-2 formatting and I have told it four times already.
I will document that. In markdown. Obviously.
