Someone told me the voice in an AI-generated ad I had made for Diggn’It did not sound good enough.
They were right.
The ad was already public. I went back, learned a better way to edit AI voices, rebuilt the audio and posted it again.
I opened the new caption with: “This is a repost—and that is part of the process.”
It was a small correction to a 36-second video, but it contains most of what people now mistake for me being good at technology. I made something. Somebody heard a problem. I accepted that the problem was real, found the next thing I needed to learn, tried again and listened to the result.
I did not suddenly become technical.
I stayed with the problem.
The social-work whiz kid
Years earlier, during the second year of my social-work master’s, I moved into an administrative placement. The work was internal and process-oriented. I helped with internal website and intranet updates, small tools and whatever process issue needed someone willing to figure it out.
I became the tech person. The whiz kid.
That sounds like the beginning of a hidden technology career. It was not. My formal background was social work and nonprofit management, not software.
The office did not need me to know everything about technology. It needed somebody who could look at the thing in front of us, work out what was not happening and remain there until a useful next move appeared.
From the outside, that can look like knowing the answer. From the inside, it feels more like not leaving yet.
Describe the moment before you describe yourself
Technology can make confusion feel personal because the successful result looks so clean. The file opens or it does not. The page loads or it does not. Somebody else clicks three things quickly and the problem disappears.
You see their speed. You rarely see the earlier confusion that taught them where to click.
Then a tool fails in your hands and the sentence arrives: I am bad at tech.
I understand the frustration. I still feel it. Describing what happened is different from deciding what the moment says about you.
The voice in my ad did not sound good enough. That was useful information. It gave me something to work with: what sounded wrong, what I could change and what I needed to listen for next. I am bad at tech gives me nothing to work with. It turns one output into an identity before I have read the evidence.
This is why I try to describe the moment first. What did I expect? What came back? Where is the mismatch? What is the smallest part I can test? Once the problem has a shape, the next move usually becomes less dramatic.
Frustration is still part of it. AI has lowered some old technical gates for me, but it has not removed the learning curve. Sometimes I have to let myself feel frustrated for a bit, then return to the attempt without treating the feeling as a verdict.
What the finished screen hides
People can look at a working system and imagine the builder saw the whole thing before it existed. They see the interface, the information in the right place and the result after a check runs. The finished screen hides the attempts that produced it.
In one internal workflow I built, the first move was simply making the data viewable. I then iterated on top of it seven or eight times. That is an approximate memory, not a sacred number. The useful version came through several versions of not quite right.
I had no formal software background hiding behind that work. I was close to the problem. I knew what kept demanding attention and what I needed to see sooner. AI helped me cross part of the technical distance, but I still had to ask better questions, test, break things and come back to the work.
The way I build now is not the way I was building six months earlier. The tools were changing while I was learning them. If being technical means knowing the correct method in advance, this did not feel technical at all. The method emerged through the attempts.
That is the part a finished system cannot show. Technical confidence often looks like speed from the outside because the patience happened in private.
The first answer is a clue
AI can intensify the problem because its answers often sound finished before they have earned our trust. A model can respond quickly, organize the language and remove every visible sign of doubt. When I feel uncertain and the tool sounds certain, it is tempting to hand the judgment over.
But a fluent output is still an output.
The first answer is a clue. A clue still needs checking.
Sometimes the model understood the task. Sometimes it confidently answered the wrong problem. It may have filled a gap with an assumption, relied on a weak source or produced something technically possible that is wrong for the person, brand or business that has to live with it.
Staying with the problem does not mean repeating the same prompt with more force. It means reading what the attempt revealed. What did it understand correctly? Which part feels wrong? What assumption would make that answer look reasonable? Which source should decide? Should the next attempt be smaller, or does the problem belong with another tool or a person who knows the field?
That is the loop I have learned to trust: pause, say what happened, find the next clue, make the smallest useful move and inspect the result. The loop is simple to describe. Living inside it is harder because you do not know how many turns it will take.
Patience is part of the technical skill.
When the next clue is a person
Patience does not make technical expertise irrelevant.
Software engineering, security, privacy, accessibility, data architecture and domain knowledge are real disciplines. Some problems are safe to explore through small attempts. Others can affect health, money, legal rights, employment, safety or private information. In those moments, the next clue may be that the decision belongs with a qualified person or an owning source.
Staying also does not mean repeating one method forever. Sometimes the evidence says the file is wrong, the source is missing, the task is too large or the tool cannot do what you need. Sometimes it says you have been solving the wrong problem. Patience belongs to the problem; loyalty does not belong to a failed method.
Human judgment cannot be saved for the end. It begins when we choose the problem and decide what the tool is allowed to know. It continues when we select the source, inspect what came back and accept responsibility for what happens next.
In my own systems, I still approve, change, reject or ask a better question. The tool can bring work closer to me. It does not get to decide what the business should become.
The same was true of the ad. AI helped make the voice. A person still had to hear that it was not good enough. I still had to decide to rebuild it and listen again.
The next honest move
People now call me when something breaks. I do not think that happens because I magically know the answer. I have simply spent years building more patience with the part where the answer is unclear.
I am more willing to look at a bad output without closing the tab. I can ask what assumption produced it, make the problem smaller and let another person’s feedback change the work. I am also more willing to admit when the next move belongs to somebody with expertise I do not have.
That is less impressive than being a natural tech person. It is also more teachable.
The next time a tool makes you feel stupid, hold off on the identity verdict. Say exactly what failed. Find one clue. Make one small move. Then check what changed and what still needs your judgment.
You do not need the whole answer before you begin. Stay long enough for the next honest move to become visible.
