Your Job May Change. That Still Does Not Make Optionality Easy.

A lot of tech writing right now has the same shape: your job is going to change, AI is moving fast, you need optionality, become AI-native, maybe build a small software business, maybe consult, maybe package your knowledge, maybe make a few thousand dollars a month on the side.

I agree with the direction. I do not agree with how easy it is often made to sound.

This post is partly a response to the genre of posts I keep seeing in newsletters like Lenny's Newsletter: pieces with titles such as "You'll lose your job in 2027" or "Your Couch-to-5K for AI." I am not linking them here because the point is not one author or one newsletter. The point is the pattern.

If someone says your current job may not exist in the same form by 2027, that is probably a useful warning. Roles are changing. Teams are shrinking. The bar for output is moving. AI is making some work cheaper, faster, and more automated. But the next sentence is often where things get hand-wavy: just build optionality, just start consulting, just launch a small SaaS, just become AI-native, just build an AI habit, just make three thousand dollars a month.

That word just is doing too much work.

Career optionality is real. But earning even a modest independent income is not easy. It takes trust, distribution, product judgment, repeated shipping, and a lot of boring follow-through.

The same thing happens with the word agentic. Everyone says you need to become agentic now. Fine. But what does that actually mean? Does it mean opening a chat window on a bloated machine and asking it to summarize a meeting? Does it mean forwarding prompts to a tool you barely understand? Does it mean buying whatever laptop the professional class currently treats as the default status object?

For me, the answer is much more concrete and much less fashionable: if you want to be truly AI-native as a builder, learn Linux.

The AI does not care about your polished UI. It needs tools. It needs file access. It needs logs. It needs shells. It needs compilers. It needs package managers. It needs processes. It needs permissions. It needs to run commands, inspect output, edit files, test, diff, and repeat. Which operating system is naturally built around that model?

Linux.

I know many people will not switch. That is fine. Use whatever works. But I do not buy the idea that the future of agentic work requires some expensive lifestyle machine. If the agent is going to operate through tools, then the best environment is the one where tools are cheap, scriptable, inspectable, and close to the system.

A used Linux laptop and AI can do an absurd amount of work. That is not a slogan for me. That is how I am now doing most of my work.

The useful part of the warning

The useful part is this: assume your role is changing. That is not fearmongering. That is probably reality.

This is not abstract for me. Losing my job or having my role change materially is a very real possibility. That is one reason I am amping up my tools, my content workflow, my software platform, my technical bets, and my publishing loop now. If that future does not happen, great. But if it does happen, I would rather have prepared while I still had time.

If your work is mostly status updates, meeting notes, basic writing, simple dashboards, repetitive analysis, or coordination theater, then AI and automation will compress that work. Maybe it will not eliminate your job immediately, but it will change what counts as valuable.

The safest response is not panic. The safest response is to move closer to work that compounds.

• Own a real system.
• Build something people can use.
• Write down what you are learning.
• Develop taste in what good output looks like.
• Understand the stack below your tools.
• Create assets that keep working when you are not in a meeting.

That part I agree with completely.

The hand-wavy part

The hand-wavy part is pretending that independent income is a quick unlock.

Three thousand dollars a month sounds small inside venture-backed tech writing. It is not small when you have to earn it from the market directly. That is thirty-six thousand dollars a year. To earn that consistently, someone has to trust you enough to pay you, keep paying you, or recommend you to others. That means distribution, credibility, positioning, billing, support, delivery, and reputation.

A small software business is not just code. A consulting business is not just expertise. A newsletter is not just writing. A course is not just recording. A YouTube channel is not just uploading. Every one of these things has a distribution problem, a trust problem, and an operational problem.

I am not saying this to discourage the idea. I am saying this because vague optimism is not a plan.

This is also where survivor bias creeps in. The person who succeeded can make the path sound obvious after the fact. They had taste, timing, distribution, network, credibility, connections, luck, and enough accumulated skill to make the move work. If you copy the surface method, you probably do not copy the hidden conditions that made it work.

That does not mean their advice is useless. It means you should read it as entertainment, signal, and directional thinking, not as a recipe that guarantees the same result.

Making money independently is not straightforward. Most businesses fail. A lot of venture-backed companies fail even after millions of dollars are poured into them. A profitable small business is difficult. A profitable small software business is difficult. A profitable content engine is difficult. If someone says “make $3k/month” casually, I want the actual path: what was sold, to whom, through what channel, after how much trust-building, with what support load, and after how many failed attempts?

Usually that answer is much messier than the clean newsletter version.

Financial defense comes before optionality theater

Here is the part I think gets skipped too often: before dreaming about independent income, protect yourself financially.

I am not giving financial advice. I am saying this from lived experience. During my entrepreneurial journey, I had to fight two banks while I could not pay credit card bills and could only keep paying my mortgage. The reason I still have my home is because I protected that cash flow as much as I could. That experience changed how I hear advice like “just make $3k/month.”

That advice can be dangerous if someone hears it as permission to spend first and figure out revenue later. AI is not free. Subscriptions are not free. Tools are not free. Cloud usage is not free. Courses are not free. Hardware is not free. If you are already deep in debt, with no savings and unstable income, “build optionality” can easily become another way to rack up bills before the business exists.

You are more likely to face debt pressure than to magically land a clean $3k/month side income on schedule. If that sounds too pessimistic, go visit a courthouse and look at how many cases are debt collection, credit, banking, foreclosure, or payment disputes. That is a more common failure mode than the clean internet story.

I learned this the hard way through disputes involving CIBC and BMO. The public BMO decision is available on CanLII. The lesson I took from that period is not “do not be entrepreneurial.” It is the opposite: build, think big, and keep taking serious swings, but protect your downside. Protect your cash flow. Minimize debt where possible. Do not let optimism about future income become the thing that destroys your present stability.

Optionality is much easier to build when you are not being chased by bills, banks, interest, and panic.

My preparation is not theoretical

I have a stable job today. I am grateful for that. But that does not make me sloppy. A stable job does not mean the future is guaranteed. It does not mean my role cannot change. It does not mean the market will care about my comfort.

This is why I am being aggressive about hardening my tools, content delivery mechanism, software platform, and technical workflow before things go down. Maybe I never need it defensively. Great. But if I do need it, I do not want to start from zero.

I already have a small ANTSHIV ROBOTICS YouTube channel with around 4.9K subscribers. That is not a massive channel, but it is real. It has been around for years. I am leaning into it more intentionally now because video, writing, carousels, and technical artifacts can reinforce each other.

I am also hardening the command center behind the work. For me that is Linux, the shell, scripts, AwesomeWM, local tools, Docker, FFmpeg, Kdenlive, Inkscape, Git, editors, and the systems I build around them. This is the part people often hide or pretend is not real. But serious developers use the command line aggressively. If you are touching software, hardware, drones, 3D, robotics, web systems, compilers, media tooling, and local automation, Linux becomes the natural default because it is versatile and close to the machine.

I talk about Linux here because agentic work is strongest when the agent can use the command line. The browser is useful. UI tools are useful. But the command line is where an agent can inspect, run, test, patch, convert, render, transcribe, compress, deploy, and verify.

I will write more about my full pipeline once I harden it and can run it consistently for a few months. The goal is simple: write the blog, generate the carousel, prepare the Reveal.js short or long-form deck, record with my setup, transcribe, edit, publish, cross-link, and repeat. Not as a content gimmick, but as a delivery mechanism for the work I am already doing.

Optionality is not a vibe

Optionality is not a LinkedIn phrase. It is an asset base.

For me, that asset base is not one thing. It is a set of long-running projects that slowly reinforce each other:

• ANTSAND, the software platform I have been building for years.
• StylesDoc, the design and rendering system that makes ANTSAND easier to harden.
• C Kernel Engine, my CPU-first inference and training runtime.
• LinuxUtilities, the practical glue that makes my Linux workflow less painful.
• DroneMath, embedded systems, soldering, sensors, flight control, and the physical engineering side of the work.
• ShivasNotes, where I can write in public and connect the work together.

None of this became optionality overnight. ANTSAND is over a decade of compounding. C Kernel Engine is a very specific bet on C, CPU runtimes, kernels, backprop, and understanding modern models from the bottom up. LinuxUtilities exists because desktop Linux still has enough friction that small repair scripts matter. The blog exists because writing helps me clarify what I am building.

ANTSAND is not a weekend project. I started working on it around twelve years ago. My YouTube channel is not a sudden reaction to AI panic. It is three to four years old. C Kernel Engine is not something I invented last week because AI became fashionable. I have been developing it for about a year, starting with GPT-2 and moving toward newer architectures, inference, training, backprop, IR, generated C, and CPU-first execution.

Even before that, my interest in machine learning goes back much further. I took Andrew Ng's machine learning course around 2010 when Coursera was starting, and I was building and controlling an RC robotics car using neural networks. I have been circling this intersection of software, math, robotics, and AI for a long time.

Someone could reasonably ask: if this has been going on for so long, why are you not already wildly successful? Fair question. Maybe I was not good enough at compounding. Maybe I did not understand distribution. Maybe I was too scattered. Maybe I am just slower than the people who make success look clean and obvious online.

That is exactly why I am skeptical of advice that makes the path sound easy. Most people are more likely to have my kind of messy, uneven path than the magical success story. The useful thing is not pretending the path is clean. The useful thing is to make a plan that compounds skills, ideas, tools, judgment, and public proof over time.

AI helps accelerate this. It does not erase the compounding requirement.

What AI actually changes

AI changes the cost of glue.

That is a big deal. A lot of useful work dies in the glue layer. Moving files. Debugging a Linux audio issue. Fixing Bluetooth. Translating a rough idea into a small script. Cleaning HTML. Generating a Sass class. Creating a carousel. Turning a transcript into a blog draft. Making a Kdenlive project easier to review. Writing a SQL migration. Explaining why an API call failed.

Before AI, many of these tasks were not hard enough to be impressive, but annoying enough to stop momentum. Now I can use AI to grind through more of that glue without pretending it is deep work.

That matters because glue is what keeps open systems usable. If AI helps me live more comfortably on Linux, use more open-source creative tools, replace paid software where possible, and make command-line workflows pleasant, then it changes my economic surface area. It makes me less dependent on proprietary stacks.

This is the same theme I wrote about in Why I Replaced QuickBooks with ANTSAND, Hardening Long Projects in the Age of AI, and Why I’m Doubling Down on C in 2026. The point is not that AI magically builds the business. The point is that AI makes it easier to own more of the stack.

Why “build a small SaaS” is not enough advice

I like the idea of small, profitable software. I would rather see more useful owner-operated software than another venture-backed unicorn cosplay exercise.

But building the app is only one part of the problem. Often it is not even the hardest part.

You still need to know:

• Who exactly is it for?
• What painful workflow does it replace?
• Why would someone trust you?
• How will people find it?
• What makes them pay?
• What makes them stay?
• What support burden does it create?
• What happens when the AI-generated prototype breaks?

This is why I think builders need a more grounded plan. Do not start with “make $3k/month.” Start with an actual wedge.

I know this from trying to sell services myself. When I was working on my business, I joined BNI. I went every Friday morning, built relationships, gave referrals, tried to sell websites, Sass, and software services, and did the real local business grind. Some years I made around $70K or more. Other years I could not pay the bills properly. That is the messy reality.

When you have a family, a mortgage, bills, and other responsibilities, the romantic version of entrepreneurship gets corrected very quickly. There are things you know would help the business grow, but you cannot afford them. There are opportunities you cannot take because cash flow is tight. There are months where you are not thinking about strategy. You are thinking about survival. At some point, looking for a job is not failure. It is responsibility.

So no, I do not buy the casual version of “just build a small SaaS” or “just earn $3K/month.” If it were easy, fewer people would need jobs. Your real path may not look like earning $70K in the first year. It may look like earning $700, learning a lot, and still needing to find work while you keep building.

A wedge can be a tool you already need. A workflow you already understand. A niche where you have credibility. A system you are already hardening for yourself. A repeated client problem. A body of writing that proves your judgment. A small utility that grows out of your own pain.

That is much less glamorous than the internet advice version. It is also more likely to survive contact with reality.

For builders, the career plan is a build plan

If you are a builder, I think the answer is not to become a motivational AI-native character. The answer is to build a compounding surface area around your actual work.

For me, that means:

• Keep hardening ANTSAND as the platform.
• Keep building C Kernel Engine as the deep technical bet.
• Keep using LinuxUtilities to remove OS friction.
• Keep turning real engineering work into ShivasNotes posts, carousels, and videos.
• Keep learning the tools that reduce dependency on expensive proprietary software.
• Keep cycling through projects in real two-to-four-month focus phases instead of pretending everything can move deeply every day.

The content is not separate from the work. It is a proof trail. If I write about thread pools, it should connect to C Kernel Engine. If I write about SVG, it should connect to ANTSAND, legal diagrams, carousels, and explainable systems. If I write about AI agents, it should connect to the actual workflow I use to build and maintain these projects.

That is the kind of optionality I trust: not hype, but a body of work.

The bets I am actually making

I do not have a guaranteed answer. Nobody does. I can tell you what I am doing. There is zero guarantee it works. But we all have to make bets.

1. ANTSAND and the digital marketing engine. I am continuing to harden ANTSAND as my own platform: websites, notes, forms, databoards, mail campaigns, syndication, blogs, assets, and eventually a tighter content and business engine.
2. Keep costs low, but be aggressive with content and scaling. I do not want a heavy subscription stack if I can avoid it. If AI helps me replace expensive tools with Linux, open-source software, command-line utilities, SVG, Kdenlive, FFmpeg, Inkscape, and my own platform, that is a real economic advantage.
3. Learn how AI actually works. Not just how to prompt it. Learn the math, physics, kernels, training loops, backprop, quantization, memory, CPU behavior, and the principles underneath the models. This is why C Kernel Engine matters to me.
4. Build seriously with AI. ANTSAND, C Kernel Engine, drones, embedded systems, Linux utilities, content tooling, and the publishing pipeline are all part of the same larger bet. I am planning in cycles, building pieces, and hoping that over months and years they unify into something powerful. It may fail. But building complex systems is still the game I want to play.
5. Use the tools deeply. For me, that means Linux plus AI. It means command line, scripts, logs, editors, compilers, package managers, local services, Docker, FFmpeg, Kdenlive, Inkscape, and boring automation. It is not glamorous, but it is cheap, powerful, and compounding.

That is my answer to “your job may change.” I am not pretending this is easy. I am not pretending this is safe. I am not pretending this will produce some clean three-thousand-dollar-a-month line item because a newsletter said it could. I am making a set of builder bets and trying to make the downside useful: more skill, more tools, more writing, more systems, more ownership.

The job may change, but the fundamentals do not disappear

AI will change jobs. Some roles will shrink. Some will disappear. Some people will become much more productive. Some people will produce more output and less understanding. Some companies will use AI to remove friction. Some will use it to create more noise faster.

The fundamentals still matter.

• Can you understand a system?
• Can you explain it clearly?
• Can you build something durable?
• Can you debug when the abstraction breaks?
• Can you create trust with real people?
• Can you ship repeatedly without burning out?

That is harder than writing “become AI-native.” It is also more useful.

The better question is not “will I lose my job in 2027?” The better question is: what am I building now that still has value if my current role changes?

If the answer is only a resume, that feels fragile. If the answer is a system, a body of work, a set of tools, a trusted audience, and proof that you can keep shipping, that feels more real.