Is the Future of My Work Writing, Typing, Drawing, and Orchestrating?

For the last few months, I have been noticing a strange shift in my work.

I am still building software. I am still thinking about AI runtimes, Linux, C Kernel Engine, Antsand, content systems, drone math, control systems, and all the engineering projects I keep returning to in cycles. But the entry point into most of this work has changed.

It is no longer always a code editor.

Most days, the entry point is a shell, a rough paragraph, a half-formed architecture note, a blog draft, a carousel outline, or a messy explanation written in broken English. I type the shape of the thing I want. Then I ask an AI agent to execute, inspect, wire, render, test, post, or refine it.

That has made me ask a real question:

Is the future of my work writing, typing, drawing, and orchestrating?

The Command Line Became the Front Door

I have always been comfortable with the command line. But recently it has become the front door to almost everything I do.

I open a terminal. I describe what I want. The agent reads files, edits drafts, runs scripts, creates HTML, renders carousel slides, checks images, posts to localhost, and prepares things for production. I refresh a browser to inspect the result. If it is wrong, I write another description. If the architecture is brittle, I push back. If the output is too generic, I sharpen the direction.

This is why my recent post, AI Is Teaching Everyone the Command Line. So Why Are We Still Ignoring Linux?, matters to me. The command line is not just nostalgia. It is becoming a control surface for AI-assisted work.

The terminal is boring, but it is powerful. It gives the agent access to scripts, project structure, logs, tests, deployment steps, and repeatable workflows. It also gives me one place to orchestrate without constantly switching between ten different applications.

AI Did Not Remove My Involvement

There is a naive version of this story where AI replaces the human and the human simply says, “make me a thing.” That is not what I am experiencing.

AI has removed a lot of friction. It can fix CSS placement issues, wire up scripts, generate boilerplate, refactor content, post drafts, inspect screenshots, and run the annoying commands I do not want to memorize every time. But it has not removed my involvement. It has moved my involvement upstream.

Before, I might have spent two hours fighting layout, file paths, image sizes, API payloads, and render commands. Now I spend more of that time deciding what the thing should be, what the structure should communicate, and whether the output is actually correct.

That is a better trade for me.

I still need to know when the agent is hard-coding logic that should come from parameters. I still need to catch when a content draft sounds like generic AI writing instead of my actual argument. I still need to notice when a diagram is visually pretty but conceptually vague. I still need to ask, “Why are we doing it this way and not that way?”

That is the part I do not want to outsource.

Writing Is Becoming the Workbench

The funny part is that my messy writing now has more value than it used to.

I can write a rough description full of spelling mistakes, incomplete sentences, and half-formed thoughts, and the agent can usually infer what I mean because the surrounding system has been hardened. It knows the project. It knows the file structure. It knows the scripts. It knows the style of the content. It knows how the local Antsand workflow connects to ShivasNotes.

That means writing is not just communication anymore. Writing is a control interface.

But it is also still thinking. When I write a blog draft, a carousel outline, or an architecture note for Antsand or C Kernel Engine, I am not merely producing input for the agent. I am forcing my own brain to organize the idea.

This is also why I do not think of my workflow as writing one or two lazy sentences and expecting AI to magically know what I mean. That is not the real work. The real work usually starts with a long idea dump. I write full paragraphs explaining the context, the constraints, the direction, the thing that feels wrong, the thing I am trying to preserve, and the thing I want the system to become.

Only after that first long-winded explanation does the loop become short. Once the agent has the frame, the corrections can be small: make this box taller, this diagram is vague, use the real dimensions, do not hard-code that, update the local draft, post it to localhost, render the carousel again. The short prompts work because the long thinking already happened.

This connects directly to my earlier post, Are AI Agents Good for Your Brain?. The answer depends on how you use them. If the agent becomes a replacement for thought, your brain gets weaker. If the agent becomes a forcing function for active explanation, your brain can get sharper.

For me, the valuable part is not “vibe coding.” The valuable part is active typing, active judging, active correcting, and active orchestration.

The Work Is Becoming a Pipeline

The more I use this workflow, the less I think of it as a set of separate activities. It is becoming one pipeline.

It usually starts with writing. I brain dump an idea, shape it into a blog post, push it to localhost through Antsand, inspect it, and then publish it to ShivasNotes when it is ready. The canonical source is not a social media post. It is my own system.

Then the same idea gets compressed. A ten-slide carousel forces me to find the spine of the explanation. A one-minute short forces even more compression. If I cannot explain cache lines, SIMD, attention, tokenization, momentum theory, PID control, or blade element theory clearly in a small format, then I probably do not understand it as well as I think.

Then the idea can go back to paper. I want to draw diagrams, write formulas, sketch systems, and explain technical ideas by hand. There is something different about using your hand to draw the structure of an idea. It slows the brain down in a useful way. It makes the weak parts visible.

Finally, the useful parts go back into the system. This is the work I wrote about in Hardening Long Projects in the Age of AI. The agent is most useful when the project itself is organized enough to accept automation. Scripts, docs, render commands, API workflows, local dashboards, and tests matter because they make the project legible to both me and the agent.

So the loop is not content for the sake of content. It is a production loop for understanding: write the idea, compress the idea, draw the idea, harden the system around the idea, and then return to the next layer with a better brain.

Going Deeper Becomes the Job

One unexpected benefit of this workflow is that it creates room for depth.

I have always been curious about how things work. But now the cost of turning curiosity into output is lower. I can read a paper, write a messy explanation, ask the agent to turn it into slides, inspect the slides, correct the weak parts, and then teach the concept. That creates a loop of reading, writing, explaining, correcting, and publishing.

That loop is basically active recall. It is also the Feynman technique. It is also a kind of spaced repetition if I keep revisiting the same ideas across blogs, carousels, shorts, code, and diagrams.

This matters because many workplaces still reward shallow velocity more than depth. But AI changes the economics of depth. If execution friction drops, the scarce thing becomes judgment. And judgment comes from fundamentals.

That is why I keep returning to Linux, C, runtimes, kernels, memory layout, CPU instructions, control systems, and math. My post Why I’m Doubling Down on C in 2026 was not just about a programming language. It was about wanting to stay close to the machine so I can reason about what the software is actually doing.

Even Hardware Starts as a Mental Model

I work in cycles. Usually three or four months at a time, one part of my work becomes dominant.

Right now, the physical drone-building cycle is paused. I am not soldering components or doing PCB design every day. I will return to that when the timing and finances stabilize. But the drone work has not disappeared. It has moved into the software and math layer for now.

I can still study control systems. I can still write algorithms. I can still reason about state estimation, Kalman filters, quaternions, motor models, propeller design, momentum theory, and blade element theory. I can still build the Linux and C foundation that will later support the hardware cycle.

This is not separate from engineering. It is upstream engineering. Hardware is not only built with tools; it is built from mental models that eventually become equations, code, tests, and physical parts. If I can explain the model cleanly on paper, I am closer to implementing it cleanly in code and eventually testing it on hardware.

That is why the writing, typing, and drawing loop matters even when I am not holding a soldering iron. It keeps the engineering cycle alive until the physical build cycle returns.

Typing Protects My Judgment

The biggest risk with AI-assisted work is not that AI writes bad code or bad content. That happens, but it is fixable.

The bigger risk is that my own judgment atrophies.

If I stop typing my own thoughts, stop drawing my own diagrams, stop reading deeply, and stop questioning the agent’s output, then I become dependent on whatever the model suggests. That is dangerous because the model will often sound confident while producing something structurally wrong.

I have already seen this in code. The agent may hard-code logic that should be configurable. It may solve the immediate task but make the system less flexible. It may generate a UI that looks acceptable but does not fit the information architecture. It may produce content that is grammatically clean but conceptually empty.

The fix is not to stop using AI. The fix is to strengthen the human side of the loop.

If I want better AI output, I need a better natural brain supervising it.

That means daily writing matters. Drawing matters. Reading papers matters. Explaining technical concepts matters. Editing matters. Saying “no, this is not the right abstraction” matters.

Orchestration Is Not Passive

Orchestration sounds passive, but it is not.

Good orchestration requires taste, architecture, sequencing, context, and correction. It requires knowing what should be automated and what should remain human. It requires knowing when the system needs a reusable template instead of another one-off output. It requires knowing when a blog post needs more personal voice, when a carousel needs a cleaner diagram, and when a code path needs a real parameter instead of another hard-coded branch.

This is why I keep hardening my own tools. Antsand is not just a website platform for me. It is becoming my publishing, notes, and workflow surface. C Kernel Engine is not just a C runtime experiment. It is a way to understand AI computation close to the metal. My Linux utilities are not just scripts. They are part of the operating environment that lets me work with less friction.

I wrote about this software ownership angle in Why I Replaced QuickBooks with Antsand. The bigger pattern is the same: I want systems I can understand, modify, and compose.

Maybe English Is the Interface

I used to think of programming mostly as writing code. I still care deeply about code. But increasingly, I think the higher-level interface is English.

Not perfect English. Not polished English. Sometimes it is ugly, misspelled, compressed, and chaotic. But it carries intent. It carries architecture. It carries judgment. It carries the shape of the work.

If my future work is writing, designing, architecting, orchestrating, analog drawing, reading, interpreting, correcting, and doing deep analysis without personally fixing every CSS issue, every API payload, every Linux command flag, every UI placement problem, and every arithmetic bug by hand, that is a good deal.

It does not mean I stop being technical. It means the technical work moves up a level.

It also changes the cadence. If I can write one blog one day ahead, that is useful. If I can write a week ahead, that becomes a system. If I can plan a month ahead, then the real power shows up: I am no longer scrambling for output every day. I am building a pipeline where thinking, drafting, drawing, rendering, publishing, and reviewing all have their place.

The work becomes: understand deeply, explain clearly, build systems that can be automated, and keep enough taste and technical judgment to know when the automation is wrong.

That is the future I am starting to see for myself.

Writing. Typing. Drawing. Orchestrating.

And underneath all of it, continuing to go deeper.