I use AI every day. A year ago, that mostly meant basic prompts: asking a question, looking up information, or getting an explanation. In 2026, I use it much more like a virtual colleague. I give it context from my emails, documents, and ongoing work so a conversation can continue from what we already know.
It sometimes agrees with me, and sometimes it argues. I value the disagreement because it gives me a chance to reconsider an idea before I put more work into it.
The change has helped me learn new skills, build software-based solutions, and get new clients. That is what interests me most: how a tool can change the work I am able to do. I still make the decisions and take responsibility for what I deliver.
Quick answer
My AI workflow has four parts:
- I give it enough relevant context to understand the task, but not automatic access to everything.
- I ask it to question assumptions, not merely make my first idea sound polished.
- I use it to build and test, then I inspect the result and take responsibility for it.
- I judge the value by the problem solved and what I learnedânot by how much text or code the system produced.
This is a personal account of how I work. It is not a universal productivity formula, and it is separate from our broader guide to using AI while exploring meaningful work.
A year ago, AI was mostly a search box
My earlier prompts were ordinary: explain this topic, summarize that idea, help me think through a small question. The interaction ended when the answer appeared.
That was useful, but shallow. The tool knew the prompt, not the work around it. It did not know which project had changed, what a client had already rejected, which constraint mattered, or why a seemingly sensible suggestion would create a problem two steps later.
I also asked questions that were too broad. If I wrote, âWhat should I do here?â, I often received a smooth list of possibilities. The list could look intelligent while avoiding the awkward details that would decide whether any option was practical.
What changed when I added real context
In 2026, I began connecting AI more carefully to the material I actually use. Depending on the task, that may include selected emails, project documents, notes, specifications, or previous decisions. The goal is not to let a system watch everything. The goal is to stop rebuilding the same context from zero every morning.
A generic assistant can suggest ways to respond to a client. A context-aware assistant can notice when a suggestion conflicts with an earlier agreement or leaves the real decision unanswered.
The result feels less like search and more like collaboration. I can ask:
- What changed since the last version?
- Which assumption am I making without evidence?
- What would break if we chose this route?
- Which part of this message needs a decision from me?
- Where do two documents contradict each other?
Those questions are useful because they connect the output to ongoing work. They still do not make the output true. Context improves relevance; it does not remove the need to check.
A working loop worth keeping
A useful working loop is to share the relevant material, separate facts from assumptions, ask for an objection, and inspect a small result before expanding it. For a website change, that means checking the behaviour in the site. For a document, it means comparing the draft with the source material. A convincing answer is a starting point for that review.
This is the discipline I recommend alongside the colleague metaphor. Context helps the system follow the work; checking the result helps the person stay in charge of it.
I want disagreement, not digital applause
One of the least useful AI habits is asking a question that already contains the answer you want. The system can become very good at decorating your preference.
I now ask for resistance on purpose. I may tell it to argue the opposite side, identify the weakest assumption, or explain why a client might reject an idea. Sometimes the objection is wrong. Sometimes it catches the exact thing I was rushing past.
This is where âvirtual colleagueâ feels accurate to me. A good colleague does not only make your document cleaner. They notice when the reasoning is thin. They ask whether the problem has been defined properly. They can say, âI understand what you are trying to do, but this part does not follow.â
AI cannot care about the outcome as a person does, and it does not carry the consequences. But it can create useful friction. I would rather correct a weak counterargument than publish an unchallenged assumption.
The biggest change was building, not chatting
The more important shift came when I started using AI to make things: small tools, website changes, automations, prototypes, data checks, and working versions of ideas that I could inspect.
This is different from asking for an explanation. Building creates evidence. A feature either behaves as intended or it does not. A test passes or exposes a problem. A workflow saves time or adds another layer of maintenance.
AI moves a vague possibility toward a testable version faster, but speed can make unfinished work look understood. Generated code can run while hiding a security, accessibility, data, or maintenance problem. A polished interface can still solve the wrong problem.
My responsibility therefore moves upstream and downstream:
- Before building: define the user, the constraint, and what success would mean.
- While building: inspect choices, ask why, and test the important paths.
- After building: review the result in the real environment and own what happens next.
The value is a useful solution I understand well enough to support.
About the phrase âvibe coderâ
I know many people in IT dislike the term vibe coder. I understand the reaction. It can make software work sound like guessing until something looks correct. That is not a standard I would accept for client work.
At the same time, the label points toward a real change: more people can now turn an idea into a working prototype without following the traditional route into development. Some will stop at the prototype. Others will learn to test, debug, review, and gradually understand the systems they are shaping.
I care less about defending the title than answering this harder question:
What can I now do responsibly that I could not do a year ago?
For me, the answer includes building and improving software-based solutions. AI helped me cross the gap between an idea and a testable version. Repeated work then taught me where generated output fails, what questions matter, and when I need deeper technical help.
Calling yourself a developer does not guarantee good work. Calling yourself a vibe coder does not excuse bad work. The client still needs something useful, secure enough for its context, maintainable, and honestly described.
New skills changed the work I could offer
I did not begin this process by choosing a fashionable new job title. I began with problems I wanted to solve.
Each project forced a new layer of learning. I had to become more precise about requirements. I learned to break work into smaller tests. I became better at reading errors, comparing approaches, checking whether an apparent fix created a different problem, and explaining the trade-off to someone who did not need the technical detail.
Those are not only AI skills. They are work skills.
Tools change quickly; a prompt trick can become obsolete. Problem definition, evidence, uncertainty, and delivery survive the next update.
Learning to build with AI helped me get new clients. That is a more concrete change than a new job label. The useful question is what I can now offer, how well I understand it, and whether I can support the result after delivering it.
Access is not the same as trust
When AI can work with email or documents, the privacy question becomes practical very quickly. âThe tool could use thisâ is not the same as âthe tool should receive this.â
I try to make access task-specific. If a document is not needed, it should not be included merely because more context might produce a slightly better answer. Names, private messages, client material, financial details, credentials, and other sensitive information deserve a higher threshold than an ordinary public note.
Before connecting a tool to real work, I want clear answers to basic questions:
- Which information can it access?
- What action can it take, rather than merely suggest?
- Where is the information stored, and under which settings?
- Can I review the result before anything is sent or changed?
- Can I remove access without breaking the rest of the workflow?
The NIST Generative AI Profile treats risk management as something that belongs across the AI lifecycle, including use and evaluation. I translate that broad principle into a simple working rule: the more personal, confidential, expensive, or difficult to reverse a task is, the less autonomy I give the tool.
Three questions before delegating a task
These questions help distinguish a useful experiment from a decision that needs closer review.
1. What data does the task require?
Use generalized or redacted information when it is enough for the task. Extra context should have a clear purpose.
2. What happens if the answer is wrong?
A rough list of meeting questions is easy to correct. A client commitment, payment, legal interpretation, health decision, production change, or message sent in my name carries a different consequence. Higher stakes need stronger review and, sometimes, a qualified human.
3. Who owns the final action?
Keep a review point before important work leaves the workspace or changes another system. Decide who will inspect the evidence, approve the action, and handle a mistake. That responsibility remains with a person, even when AI does much of the preparation.
A virtual colleague is still a tool
The metaphor has limits. AI does not have a career, a family, a reputation, or a relationship with the client. It does not feel the cost of a bad recommendation. It can produce confident language without the lived experience behind it.
That is why I do not outsource meaning to it. The system can help me compare options or prepare a small real-world experiment. It cannot decide which work is worth doing or which responsibility I want to carry.
The International Labour Organizationâs 2025 update on generative AI and jobs examines exposure at the level of occupations and tasks and emphasizes transformation more than a simple story of entire jobs disappearing. That task-level view matches my experience. My title did not change overnight. The set of tasks I could attempt, combine, and deliver changed first.
What this taught me about meaningful work
AI did not reveal a hidden purpose to me. It changed the feedback loop.
Instead of thinking for weeks about whether I might be able to build something, I could create a small version and learn from it. Instead of accepting the first plan, I could ask for an objection and improve the question. Instead of waiting until I felt qualified for a new label, I could practise one concrete skill and see whether it helped someone.
That is close to how we approach self-discovery elsewhere at Ikigain. A work-values result can suggest what to examine, and a career-interests result can point toward activities to test. Neither makes the decision. Evidence accumulates through action.
The meaningful part was not having AI. It was solving new problems, becoming useful through practice, and building client relationships around the result.
What I would tell myself one year ago
I would not say, âFind the perfect prompt.â I would say:
- Choose a real, contained problem.
- Give the tool only the context needed for that problem.
- Ask it to challenge your plan before it helps execute it.
- Build something small enough to inspect.
- Test the result where it will actually be used.
- Record what you learned, including what failed.
- Keep responsibility for the outcome visible.
The useful change came from learning what I could do with the tool and getting better at checking the result. I would start with that practice again.
FAQ
What does it mean to use AI as a virtual colleague?
For me, it means giving AI enough task-specific context to help organize work, challenge assumptions, and build testable outputs across an ongoing project. It does not mean treating the system as a person, giving it unrestricted access, or transferring responsibility for decisions and consequences.
Do you let AI read all your emails and documents?
No. Access should be deliberate and limited to the task. I prefer selected, redacted, or generalized material when that is sufficient, and I keep a human review step before consequential actions. Anyone considering connected AI tools should check the providerâs current privacy, retention, permission, and data-use settings for their own account and jurisdiction.
Did AI turn you into a developer or âvibe coderâ?
AI helped me build, test, and improve software-based solutions and develop skills I did not have a year earlier. I am less interested in defending a label than in whether I understand the result, test the important behavior, communicate limits honestly, and can support the work delivered to a client.
Can using AI help someone find new work?
It can expand what a person can learn, prototype, or offer, but the tool does not guarantee clients or meaningful work. In my case, new capabilities helped me approach new client problems. The opportunity came from combining the tool with judgment, repeated practice, communication, and responsibility for the final result.
What should I never delegate completely to AI?
I would not delegate the final responsibility for a client commitment, a production change, a sensitive message, a payment, or a decision that affects someoneâs health, rights, privacy, or livelihood. AI can prepare options and expose questions; I still need to inspect the evidence, make the decision, and own the consequence.
