A manifesto for young builders entering a world where the old path into technology is changing.
The Fading Ladder
If you’re graduating into the age of AI and quietly wondering whether the future closed before you arrived, this is for you.
The fear is not irrational. The old path into technology is changing. The junior engineering job was never just a paycheck; it was an apprenticeship. It taught people how real systems worked, how teams made decisions, how products failed, and how trust was earned.
AI is now absorbing many of the beginner tasks that used to help people climb that first rung.
But that does not mean you are doomed.
It means the path is changing.
For a long time, the path into technology had a familiar shape. You studied, you applied, you got an internship, then a junior role, then you slowly learned the craft inside a company that already had customers, systems, managers, deployment processes, and older engineers around you. You were not expected to understand everything on day one. You learned by fixing bugs, writing small features, reviewing logs, sitting in meetings, breaking things carefully, and watching how experienced people made tradeoffs.
That path was imperfect. It excluded many people. It rewarded credentials, geography, timing, social networks, and luck. But for those who entered it, it provided something valuable: a structured way to become useful before you were fully formed.
The fear now is that AI is removing the work that used to train beginners.
This is not just about coding. It is about the ladder. When an AI system can generate a component, write a script, summarize documentation, draft a test, produce a landing page, refactor a function, or explain an API faster than a junior employee, companies start asking different questions. How many beginners do we need? How much supervision can we justify? How much training can we afford? What work is still safe to hand to someone with no track record?
That is a serious change. Pretending otherwise is not optimism. It is denial.
Young people can feel this before the institutions admit it. They read job postings asking for three years of experience for “entry-level” roles. They see layoffs. They see AI demos. They see founders building products with tiny teams. They see experienced people using tools that make them even more productive. And then they ask the quiet question:
Where do I begin?
That question deserves respect.
Beyond Doom and Denial
Too much advice to young builders is either shallow optimism or shallow doom.
The shallow optimist says, “Don’t worry, AI will create new jobs.” Maybe it will. But that sentence does not help someone who needs a path now.
The shallow doomer says, “Everything is over. The machines will do it all.” That is also lazy. It turns uncertainty into paralysis and gives people permission to stop trying before they have discovered what they are capable of.
The truth is harder and more useful: the old ladder is weakening, but a new path is forming.
The new path is the builder path.
A builder is not just someone who writes code. A builder is someone who turns ideas into proof. A builder learns by shipping. A builder understands that a demo is not a product, a product is not a company, and a company is not just a website with pricing. A builder uses AI as leverage, but does not confuse leverage with judgment.
This path does not begin with permission.
It begins with proof.
The Proof-Maker
Proof can be small.
A working prototype. A useful tool. A landing page that explains a real problem clearly. A customer conversation. A tiny automation that saves someone time. A public case study. A community of ten people who care. A video showing the product working. A failed launch with honest lessons. A support conversation handled well. A system that keeps running when nobody is watching.
Proof looks different by field.
For a designer, proof might be an interactive prototype that solves a real user flow and has been tested with actual users. For a writer, it might be a newsletter, research brief, or essay series that attracts a specific audience. For an operator, it might be a repeatable process that saves a team hours every week. For a community builder, it might be a small group where people return, contribute, and help each other. For a product thinker, it might be a clear customer problem, a working mockup, and evidence that someone wants the solution.
The form changes. The principle does not.
Proof beats permission.
That can sound unfair, but it can also be freeing. You no longer wait for a perfect gatekeeper to recognize your potential. You create the trail yourself. You show your taste, your discipline, your curiosity, your resilience, your ability to learn, and your ability to finish.
AI makes this more possible, not less.
AI removes friction, not judgment.
It accelerates building, but it cannot decide what is worth building, care about a customer, or take responsibility when things fail.
That part is still yours.
Pieces vs. Systems
The future belongs less to people who merely know how to perform isolated tasks and more to people who can connect tasks into systems.
That is the deeper change.
The old entry-level path often started with fragments. Fix this bug. Build this page. Write this query. Update this document. The company held the system. The beginner contributed pieces. Over time, the beginner learned the system.
The new builder path may require you to encounter the system much earlier. You may need to understand users, distribution, pricing, onboarding, reliability, data, support, security, deployment, brand, and trust before anyone gives you a formal title.
That can feel overwhelming.
But it is also the opportunity.
Because when you learn systems, you become harder to replace.
A system is not just architecture. It is the relationship between promises and reality. A product promises something to a user. The system is everything required to keep that promise: the interface, the data model, the permissions, the billing, the email, the logs, the error handling, the customer support, the documentation, the deployment process, the team habits, and the moral decision about what not to do.
AI can generate pieces.
Builders learn how the pieces hold together.
Lessons from Previous Shifts
I learned this before AI, but the lesson is even more important now.
When I was young, I did not begin with ideal conditions. I had constraints. I had to figure things out with whatever was available. Constraint teaches a powerful lesson: the world does not hand you a path. You learn to notice what people need, what you can make, what you can sell, what you can improve, and what you can try next.
Constraint creates builders because it removes the fantasy that someone else will arrange everything for you.
Later, in the pre-iPhone mobile era, I worked on Mobileplay with James Ryan. The world was shifting then too. Phones were becoming more capable, but the ecosystem was fragmented across Palm OS, BlackBerry, Windows Mobile, Symbian, Java phones, Treos, and early smartphones. Distribution was strange. Browsers were limited. Users were hard to reach.
But that platform shift created openings. Mobileplay delivered mobile content from major publishers and media brands to millions of users. At one point, Opera Mini distribution put Mobileplay in front of people through one-click access inside the browser.
The lesson was not “mobile is easy.” It was the opposite. Platform shifts are messy. They create confusion before they create opportunity. But inside that confusion, new builders can enter.
AI is that kind of shift.
Not identical. Bigger in some ways. Faster in some ways. More destabilizing in some ways. But the pattern is familiar: old assumptions break, new tools appear, distribution changes, small teams can do things that once required large teams, and people who understand the new environment early can create surprising value.
Another lesson came from infrastructure.
In the early days, our first server cost one dollar on eBay, plus thirteen dollars for shipping. That detail still makes me smile, but it also captures the reality of building at the edge of what you can afford. We set up machines, configured DNS, and spent hours with large network providers getting reverse DNS authority delegated to our own name servers. It was not glamorous work. It was the hidden work behind making a real system visible and trusted by the rest of the internet.
Years later, after we had moved into a server facility, an outage still traced back to old garage infrastructure when my dad called and said the power at home had gone out.
That is funny now, but it contains a serious truth: hidden systems matter.
Most people see the product. Builders learn to see what the product depends on.
Trust Is the Currency
AI can make prototypes look polished very quickly. It can create the feeling of progress. But the hidden systems still matter. Identity matters. Permissions matter. Data boundaries matter. Billing matters. Reliability matters. Auditability matters. Support matters. Deployment matters. Trust matters.
A prototype can impress people.
A real product has to survive contact with users.
That is why the builder path cannot be only about “learning to prompt.” Prompting is useful, but it is not enough. The new builder needs a broader craft.
You need to ask better questions, test assumptions quickly, talk to users before you pitch, and learn to read systems, not just code. You need to create proof that someone else can inspect.
Most of all, you need to build trust.
When anyone can generate a landing page, trust moves to evidence. Does the product work? Do users come back? Can the team explain the tradeoffs? Is the system secure enough for the promise being made? Are the claims honest? Does the builder understand the customer? Is there a real path from demo to durable value?
This is where young builders still have enormous room to matter.
You may not have decades of experience. You may not have a famous school or a famous company on your resume. You may not have investors, press, or a network. But you can create visible evidence. You can pick a real problem, stay with it longer than the tourists, document your process, and keep improving in public.
The builder path does not eliminate every barrier. It still helps to have time, internet access, support, and some financial breathing room. We should not pretend otherwise. But it can reduce the power of some old gates by giving more people a way to create visible evidence before they are invited inside.
The important question is not “Can you code everything yourself?”
The important question is:
Can you turn insight into something real?
That opens the door wider than the old path did.
Building the New Ecosystem
But only if we build the right ecosystem around it.
This cannot be solved by one company, one school, one tool, one accelerator, one investor, or one founder community. It has to become a broader movement.
Schools need to teach students how to create proof, not just complete assignments. Companies need new apprenticeship models for the AI era. Founders need to invite younger builders into real work without pretending unpaid chaos is mentorship. Investors need to recognize builder proof that does not look like traditional credentials. Communities need to help people find collaborators, feedback, standards, and courage. Infrastructure companies need to make it easier to turn AI-generated prototypes into safe, durable, real products.
Two early experiments in this direction are CatsDojo and ScaleMule.
CatsDojo is one attempt to create a serious builder environment where people can move from idea to company with more support, more discipline, and less isolation. ScaleMule is one attempt to solve the infrastructure problem behind the builder path: helping AI-assisted products move beyond demos into real systems with identity, tenants, events, storage, billing, auditability, and operational control.
They are contributions, not the whole answer.
Other people will build different answers.
They should.
We need many attempts. Many communities. Many tools. Many schools. Many studios. Many founders. Many investors. Many paths.
The old ladder is not coming back in the same form, so we need to build new ladders.
First Moves
So what do you do first?
Start small, but make it real.
Pick one problem you understand. Build one useful thing. Show it to one real person. Ask what confused them. Improve it. Write down what you learned. Repeat.
Do not begin by trying to look impressive. Begin by trying to become useful.
Ship one small tool this month. Publish one build note each week. Find three to five other builders for regular feedback. Talk to users before you polish. Keep a public record of what you tried, what worked, what failed, and what changed.
That is how proof begins.
Not with a perfect plan.
With motion.
You Are Not Doomed
We should not tell young people that nothing has changed. They know that is false.
We should not tell them they are doomed. That is also false.
We should tell them the truth: the path is harder to see, but not closed. The first rung may no longer look like a junior job at a large company. It may look like a shipped product, a useful tool, a customer conversation, a public build log, a small community, a working integration, a case study, a failed experiment, or a system that proves you can be trusted with more.
You are not doomed.
But you cannot build the way the last generation built.
You must become a proof-maker. You must use AI without surrendering your judgment to it. You must learn systems, ship real things, and build trust before status arrives. You must create value where you stand instead of waiting for someone to define your role.
The future did not close before you got there.
The door simply changed shape.
Now we have to teach a generation how to open it.