Is AI Really Helping Us?

Where I stand

Before I answer, I should say where I am standing. I build software for drones and AI agents, and I am a co-founder of PAWAAC Drones. Most of the software on this site was built with AI coding tools: Claude Code, Kiro CLI and Codex CLI. So I am not writing as someone who fears AI, and I am not writing as someone selling it. I use it every day, and I have seen both what it does well and what it slowly does to the person using it.

People sometimes ask how much of that software the tools did. The honest answer is: most of the typing, and much less of the work. Typing was never the hard part. The hard part is knowing what to build, deciding how the pieces fit, finding out whether it actually works, and standing behind it when it does not.

So here is my answer, up front. AI helps when it is the helper. It hurts when it becomes the owner. In my own work, the best result in the least time comes when AI does about four parts of the work in ten and I keep the other six, and those six must be the ones that decide. The rest of this article is how I arrived at that, and how you can test it against your own work.

The question is about the hand

Those who praise AI and those who fear it usually make the same mistake. They look at what the tool can do and argue about whether that is good or bad. A tool is neither. The same tool in two different hands gives two different results. The real question is always who is holding it, and for what.

This was true long before AI. Give two engineers the same laptop, the same software and the same deadline, and their work will be nothing alike. The difference is never the laptop. It is what each of them understands, what each has practised, and whether each knows why the work is being done at all.

Musashi complained that in his time the martial arts had been turned into something to sell, all display and little substance:

AI makes flowers very easily. A page of writing, a design, a working program appears in the time it takes to make tea, and it looks finished. Whether there is any fruit behind it is a separate question: whether it is correct, whether it fits the people it is for, whether it will hold up on a bad day. That question is answered by the person using the tool, or it is not answered at all.

What AI is actually like

The best way I have found to describe AI is to imagine a new member of the team.

Suppose someone joins us who has read every textbook on flight control, the documentation of every autopilot, and every research paper and forum thread on drones ever written. Ask him anything and he answers at once. He writes a first draft of whatever you ask for in seconds. He never gets tired, never sulks, and will work with you at two in the morning without complaint.

But he has never stood in a field at six in the morning with a drone that will not hold its position in a gusting wind. He has never had to tell a customer that a flight is cancelled, or explain to the team why a test failed. He does not know our airframes, our customers, the site we fly at tomorrow, or the mistake we made last month. If the drone comes down, his name is not on the report. And he says what he knows and what he is only guessing in exactly the same confident tone, because to him there is no difference between the two.

That is AI. Everything it knows, it knows from what other people wrote down. It has read more than any of us could read in a hundred lifetimes, and it has lived none of it.

Musashi compared the bow with the gun:

AI’s answers are like the bullet. You see where they land. You do not see how they got there, and the tool cannot truly show you. When you cannot watch the flight, you have to inspect the landing twice as carefully.

What a helper like that is good for

A leader who had a team member like this and refused to use him out of pride would be foolish. He is enormously useful, and I use him every day.

He can remind me of things I have forgotten. He can tell me how other people have solved a problem, so that I do not start from nothing. He can write the first version of something I have already decided, so that I can cut it down and reshape it. He can do the same kind of task a hundred times without getting bored. He can read a large, unfamiliar codebase and tell me where things are. He can show me three ways of doing something, so that I can choose. All of this is work that must be done, and all of it takes time I would rather spend on the parts that decide.

A person who uses AI for these things gains many hours and loses nothing.

Why it cannot own the work

But I would never send this new team member alone to the field for a customer’s first flight.

Not because he is weak. In a written test he might beat all of us. I would not send him because real work is not a written test. It is one particular job, for one particular customer, on one particular day, under one particular sky, and everything that matters is in those particulars. He knows the general case perfectly and the particular case not at all. And when the day is over, it is my team and I who live with the result, not him.

Every serious piece of work is like this. It is for a particular purpose, for particular people, under particular conditions, and someone must answer for it afterwards. That someone is the owner. The owner is not the person who did the most typing. The owner is the one who knows why every part is the way it is, who can find what went wrong because he knows where each piece was put, and who carries the result when the work meets the world.

The most important thing I have learned as a co-founder is that you can hand over work, but you cannot hand over responsibility. When a drone falls, nobody asks which tool wrote the code. They ask who signed off on it.

AI cannot be the owner, because it does not know the particulars and it carries nothing. It can only be a helper. A helper can be excellent. But the moment you let the helper decide, you have sent the new member of the team to the field alone.

Musashi taught that in a fight you should treat everything around you, even your opponents, as your own forces, and move them as you intend:

With AI, this turns around without your noticing. You ask it something and do what it says. You ask the next thing it suggests, and do that too. A few weeks later you are no longer directing the tool; it is directing you. It has become the general, and you are its soldier. I watch myself for this more than for anything else.

Among the rules Musashi kept for his own life was this one:

I hold AI the same way. Respect what it can do. Do not come to depend on it, because a person who depends on something he does not understand has nothing to stand on the day it fails him.

What is lost when AI does the hard part

It becomes light in only one way: by being lifted, many times, by you. Nobody can lift it for you, and watching someone else lift it does not put strength in your arm. Every skill I have, I got by doing the work badly first, then less badly, many times over.

When we cut power to a motor mid-flight at Inter IIT Tech Meet 13.0, I was nervous. But I knew why the controller should hold, because we had spent months tuning it. It held. No tool can give you that kind of knowing. You earn it, one hard hour at a time.

The person who gives all his work to AI notices no loss at first. The work is done, and it looks good. But the parts of the craft he no longer practises grow weak in him. After a year he finds he cannot tell good work from bad, because he has not done enough of either with his own hands to feel the difference. So he asks the AI whether the AI’s work is good. He has handed over not only the doing but the judging, and he did not notice when it happened.

This is my answer to those who say AI will ruin the minds of the young. It will not, by itself. What ruins a young engineer is skipping the part of the work that would have taught him, and AI makes that part very easy to skip. So the discipline has to come from the person.

Musashi put it this way:

There is no shortcut in that sentence, and AI has not added one. It can take away the errands. It cannot do the thousand days for you.

There is also the matter of your name. If you put your name on work you did not examine, and it fails, what will you say? That the AI made it? Then it was never your work, and your name did not belong on it. Whatever else you give up, keep the right to say of your work: this is mine, and I know why it is so.

The reckoning of forty and sixty

I have said AI should help but not own. Now I want to show how much it should help, with numbers, using an example from my own work.

Suppose I am planning a day of test flights: ten flights, and planning all of them myself takes ten hours. For each flight I have to decide what it is testing, which battery and payload it carries, how high it goes, the wind speed at which we stop, and where the safety pilot stands. I can hand some of the flights to AI. It plans any one of them almost instantly, so its time can be counted as nothing.

But I cannot simply accept its plan. A flight is only right if it fits the flights around it. The battery it needs must have finished charging. What it tests should depend on what the flight before it proved. It has to finish before the light goes or the field permission ends. To judge one of AI’s flights, I have to know the flights on either side of it. If I planned those myself, I can see at a glance whether its flight fits. If I did not, I have to work them out too before I can judge. So the more flights I hand over, the more each one costs to check, because less of the day is already in my head.

Now some numbers. Say that checking one of AI’s flights costs an eighth of an hour for every flight I handed over. Then if I hand over all ten, checking the whole day costs twelve and a half hours, a little more than planning it myself. That is fair, and anyone who has had to sign off on a plan written by someone else knows it. To put your name on a flight you did not plan, you have to understand it as well as whoever planned it, and then also find what they missed. The reckoning is:

• Hand over nothing. I plan for ten hours. Ten hours in all.
• Hand over two flights. I plan for eight hours, and checking the two costs a quarter of an hour each. Eight and a half hours.
• Hand over four flights. I plan for six hours, and checking the four costs half an hour each. Eight hours, the least of all.
• Hand over six flights. I plan for four hours, and checking the six costs three quarters of an hour each. Eight and a half hours, and now more of the day is AI’s plan than mine.
• Hand over all ten. I plan nothing, and checking costs an hour and a quarter for each flight. Twelve and a half hours: longer than doing it myself, and I still do not know the day as well as if I had planned it.

Two flights and six flights cost the same. With too little help, I waste the tool. With too much, I drown in checking its work. The least time comes at four parts given and six kept.

You may say I chose the eighth of an hour, and that a different number would give a different answer. That is true. If checking is quicker in your work, the best share moves toward five; if it is slower, toward three. But one thing does not move. Checking complete work you did not make cannot cost less than making it, because you have to understand it as well as its maker before you can even begin to look for mistakes. As long as that holds, the best share for AI in this reckoning is never more than half, whatever number you pick. The owner always keeps the larger part, and the only reason is that understanding is not free.

Time is not the only thing this decides. At four given and six kept, the flights I planned surround the ones AI planned, and the whole day is still in my head. When the wind picks up at noon, I know which flights to move and which to cancel. At six given and four kept, most of the day is a stranger to me. Past half, the plan is AI’s, whatever name is written on it. So forty and sixty is not only the quickest division. It is the one where the work is best and still mine. Try it against your own work and see whether it holds.

Which forty and which sixty

It is not enough to hand over four parts. They have to be the right four. If you give AI the decisions and keep the errands for yourself, you have split the work in the right proportion and still ruined it.

Give AI the work that suits a helper:

• Collecting what is already known and written in many places.
• First drafts, which you will then cut down and reshape.
• Work that repeats, where the tenth piece is the same as the first.
• Arranging and tidying what has already been decided.
• Showing you several versions of something, so that you can choose.
• Finding details you would otherwise have to look up.

Keep for yourself the work that belongs to the owner:

• Deciding what the work is for, and for whom.
• Knowing the particulars: the people, the conditions, and what has gone wrong before.
• Choosing among what AI has offered, and throwing most of it away.
• Deciding how the parts fit together.
• Testing the work against the real world, not against AI’s description of it.
• Answering for the result.

How much of a job is gathering and how much is deciding changes from one kind of work to another. The code that keeps a drone in the air needs a far larger share of my own judgment than the code for a landing page, because a mistake in one falls out of the sky and a mistake in the other is only embarrassing. Know your own work well enough to see where its deciding parts are. But in every kind of work, the owner keeps the larger share, and keeps the parts that decide.

When to take the wheel back

Some sessions with AI go well and some do not, and it is worth learning to feel the difference early.

There is a good rhythm, where the tool clears away the errands so that my mind is free for the parts that decide. And there is a bad rhythm, where I ask, it answers, I ask again, it answers again, and an afternoon goes by while I believe I am working. I have had both kinds of afternoon, and I have learned to notice which one I am in.

AI has a rhythm of its own as well. It answers at once, every time, with the same calm certainty whether it is right or wrong. If you fall into that rhythm, you start deciding at once too, without weighing anything. Keep your own pace: quick where the matter is simple, slow where it is not.

This holds with AI. If I have asked for something twice and it has not come out right, I do not ask a third time in the same way. The third answer is usually the first answer in different clothes. I change my approach, or I put the tool aside and do that part myself. Often that takes less time than the asking did.

The rules I work by

These are the rules I hold myself to, and the ones I ask of anyone who builds with me:

• Never put your name on something you have not examined.
• Ask AI for material, not for decisions.
• Decide what done looks like before you ask for anything.
• Read what it gives you the way you would read work from a stranger: politely, and with doubt.
• Ask it where it might be wrong, and check those places yourself.
• Do the hard part yourself, especially when you could hand it over.
• Keep some of each day’s work entirely your own, so the skill stays.
• When it fails twice, stop asking and do it yourself.
• Test against the real thing: the drone, the user, the field. Not against the tool’s summary of it.
• Never hand over the decision about what the work is for.
• Answer for everything that carries your name.

Keep these, and AI will make you faster without making you weaker. That is the only kind of help worth having.

So, is it helping?

Back to the question I was asked: is AI truly helping people?

It is helping those who use it as a helper. They finish sooner, their work is better, and they grow stronger at what they do, because the tool takes the errands and leaves them the parts that teach. For them it is the best helper there has ever been.

It is not helping those who have made it the owner. They also finish sooner, at first, so they believe they are being helped. But the work is no longer theirs, their judgment weakens without their noticing, and on the day the tool cannot carry them, they find they cannot carry themselves. For them it is a slow injury that feels like help.

The tool is the same in both cases. The difference is the person holding it. Let it do four parts in ten. Do the other six yourself, and make sure they are the six that decide. Then the work is done in the least time, it is as good as it can be, and it is yours.

The helper brings speed.

The owner brings judgment.

The work needs both, and belongs to one.