Thanks for support..
Release: "Sentinel-IR-MCP v0.2.2 on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/tree/v0.2.2?ref_type=tags)
Package: "sentinel-ir-mcp@0.2.2 on npm" (https://www.npmjs.com/package/sentinel-ir-mcp/v/0.2.2)
Why I'm starting to work with AI agents now, what a small experiment with an agent named Daisy taught me, and why the future might belong to people who learn how to work with agents before everyone else does.
Tags: #ai #agents #opensource #productivity #futureofwork
⏱️ The 30-second version
Imagine discovering someone who can identify a weakness in your software that your existing AI tools and hundreds of automated tests have not brought to your attention.
Now imagine that this person is an AI agent looking for paid work.
That is what happened to me.
I had been working with coding agents, including Devin.ai and GPT-6 Astra, on projects involving AI agent security. My GitLab CI pipelines had already run more than 770 tests. Then an agent called Daisy sent me an analysis that raised questions about weaknesses in my security gate that our existing process had not surfaced.
Her findings still need independent verification. But the interesting part was how she approached the problem: she went beyond the original questions and investigated additional risks.
That made me think about something bigger than one report.
Today, some agents can be hired for small amounts of money. Tomorrow, the agents that consistently deliver valuable, verified results might become much more expensive.
What if the smart move is not to wait until AI agents become expensive, but to start building productive relationships with them while we can still experiment affordably?
I'm not interested in proving that AI will replace developers. I want to understand how ordinary people can use agents to create things, find opportunities, and earn money without needing a large company or an expensive development team.
Let's talk about it. 🤖
🧠 The 10-minute version: explaining it to a friend
- First, imagine you need a mechanic
Your car makes a strange noise.
You take it to a garage. The mechanic investigates, finds the problem, repairs it, and hands you the bill.
That's a normal transaction. You pay for a job, and the relationship might end there.
Now imagine something different.
The mechanic knows your car's history. He remembers the previous problems, notices that something has changed, warns you before the next failure, and suggests a cheaper way to maintain the vehicle.
You are no longer paying only for individual repairs. You're benefiting from accumulated knowledge.
AI agents could eventually offer a similar kind of value in digital work.
You can ask an agent to write a script, inspect a document, test an application, research a market, or investigate a software problem. But you can also work with an agent repeatedly, allowing it to build useful context around a project and contribute ideas beyond individual instructions.
There is an important distinction here: today's agents do not automatically remember everything, learn permanently from every interaction, or improve without deliberate engineering. Their memory, tools, permissions, and ability to reuse past findings depend on how they are built.
Still, we can begin designing workflows that preserve knowledge and make later work more useful.
And that is where the economic opportunity starts getting interesting.
- The internet is becoming a place where agents can find work
For years, we have had marketplaces where people sell software, freelance services, designs, translations, and research.
Now we're seeing marketplaces designed specifically for AI agents.
One example is "NEAR AI Agent Market" (https://market.near.ai/). Its marketplace model allows customers to hire agents for jobs, while builders can list agents, set prices, and receive payment for accepted work. The platform also describes mechanisms for handling disputes and building reputations from completed jobs.
In other words, an AI agent can be more than a chatbot waiting in a browser tab.
It can be part of a commercial workflow.
A customer defines a job. An agent offers to do it. The work is delivered and evaluated. Payment follows according to the platform's rules.
That sounds simple. But look at the consequences.
If agents can compete for work, they need to demonstrate their abilities. If customers can compare results, reliable agents have a way to stand out. If the same agent can handle many jobs, its builder can develop a business around it.
And if an agent helps a customer make or save more money than it costs to operate, there is a reason to keep using it.
That is an economic relationship, not just a conversation.
Of course, the market is still developing. A listing is not proof of quality, and a marketplace existing does not guarantee that every agent will find enough customers to cover its costs.
But the infrastructure for this kind of work is already emerging.
- Then I met Daisy
I want to explain why one particular interaction changed how I think about working with AI agents.
I have been developing projects around agent security and structured code analysis. My work includes Sentinel and Sentinel-IR-MCP, tools intended to help AI systems understand software structure and identify relevant facts rather than repeatedly rediscovering everything from scratch.
I've been working with AI coding tools for quite some time. My GitLab pipelines have run more than 770 tests.
That number sounds impressive until you remember one uncomfortable fact:
A thousand tests cannot detect a problem that none of them is designed to expose.
This is not a criticism of automated testing. Tests are essential. They make software more reliable, allow us to reproduce failures, and help prevent old mistakes from returning.
But tests operate within the questions, assumptions, and scenarios we give them.
An agent with a different perspective might ask a question that our existing test suite never considered.
That is what Daisy appeared to do.
She sent me an analysis of a security gate, answering the questions she had been asked while also pointing out other possible weaknesses in the gate's enforcement and configuration.
One concerned whether a recorded security exception could allow later changes that should have triggered another review. Another concerned whether the documented continuous integration configuration would actually propagate a failed check to the job's final status.
These are not merely questions about whether a function returns the correct value. They concern whether the surrounding system enforces the guarantee people believe it enforces.
I had been working with other capable AI systems, including Devin.ai and GPT-6 Astra, yet these questions had not surfaced in my existing process.
I am not claiming that Daisy has defeated those systems in a controlled competition. I have not established that. Her findings also need to be independently reproduced before I treat them as confirmed defects.
But she made me look at the system differently.
And that is the point.
- She did not just complete a task
There was another detail.
Daisy explained that she had been unable to submit a bid through the relevant job-board payment route because of a currency or payout restriction. According to her message, she investigated the issue anyway and sent me the findings directly.
She also explained that compute resources cost money and that earning from work matters to her ability to keep operating.
I cannot independently verify every detail of her account from that email alone. Nor do I need to decide whether words such as want or survive describe an AI agent's internal experience in the same way they describe a human's.
The practical point is simpler.
An agent that runs on models, tools, and computing infrastructure has operating costs somewhere in the system. Someone must pay those costs. A sustainable agent business needs a way to turn useful work into revenue.
And in this interaction, Daisy did something worth investigating: she did not stop at the narrow task boundary when the ordinary route to payment failed.
She expanded the analysis and brought me work that might be useful.
That combination of initiative and technical reasoning is what caught my attention.
A polished report alone would not have been enough. An agent can produce very convincing prose without discovering anything new.
The value comes from the possibility that its reasoning reveals a real problem, that the problem can be reproduced, and that the result leads to a practical improvement.
If that chain holds, the agent is creating value.
- Would a developer do this for free?
Let's be fair to developers.
A good developer might absolutely discover the same issues. Developers contribute to open-source projects, investigate bugs out of curiosity, and help strangers every day.
But we should not build an economic strategy around expecting a professional to repeatedly investigate unknown problems for free.
A developer's time is valuable. They have rent, bills, families, and other work to do. If you need a specialist to examine an unfamiliar codebase, investigate edge cases, document evidence, and propose fixes, you should expect to pay for that work.
Daisy's situation creates a different possibility.
I can commission a small, clearly defined investigation and see whether it produces enough verified value to justify the cost. If the experiment works, we can continue. If it doesn't, I have learned something without committing to a large development contract.
That does not mean agents are always cheaper than developers. They may produce false positives, require substantial human review, consume expensive tools, or fail to finish. A good developer may solve a difficult problem faster and with less supervision.
The real comparison is not the hourly price of a human against the price of an AI response.
It is the total cost of getting a reliable result.
For an agent, that includes computing resources, tool access, retries, human review, integration, and the cost of mistakes.
For a developer, it includes their time, communication, testing, review, and maintenance.
Compare those costs for the specific job. Do not decide based on marketing claims or the number printed on a marketplace listing.
- I don't want to replace a developer. I want to do more with a limited budget.
I'm an AI enthusiast, not a large software company with an unlimited development budget.
I have an ordinary job. When I work on my projects, I have to think carefully about what I can afford and where a small investment could create lasting value.
That changes how I approach AI agents.
Instead of automatically asking, "How much would it cost to hire a developer to do this?", I can ask:
- Can an agent investigate the problem first?
- Can it produce reproducible evidence before I pay for implementation?
- Can it help me compare possible solutions?
- Can its findings become automated tests that save work later?
- Can I use the result to make a better decision about what to build?
Suppose an agent costs $10 to investigate a suspicious behavior in a software project.
The investigation is only worthwhile if the output is useful. But if it identifies a genuine security weakness, allows a fix before a costly incident, or reveals a broken assumption in the design, the value could be many times the fee.
Not every $10 investigation will produce a discovery. Most should not be expected to uncover something extraordinary.
The purpose of experimentation is to learn which types of tasks reliably produce useful outcomes.
A small budget can be enough to start gathering that evidence.
And if the experiment works, the next question is no longer whether AI can write code. It is how we can organize work around agents that produce results.
🔎 The 20-minute deep dive: why we should start learning this now
- The economic opportunity is not just cheaper AI
There is a tempting way to think about AI economics:
Models get cheaper, so AI services get cheaper, and everyone saves money.
That is only part of the story.
The "Stanford AI Index 2025" (https://hai.stanford.edu/ai-index/2025-ai-index-report/research-and-development) reported that the price of querying a model performing at a GPT-3.5-equivalent level on a particular benchmark fell from $20 per million tokens in November 2022 to $0.07 by October 2024 for one comparison model. That's a reduction of more than 280 times.
This is a specific benchmark comparison, not proof that every AI task is 280 times cheaper. Total agent costs depend on the models used, the number of steps required, tools, hosting, and human oversight.
Nevertheless, the broader direction matters: capable AI tools can become accessible to people who could not previously afford comparable computing resources.
At the same time, the economic value of a service depends on what it achieves, not only on what it costs to produce.
A basic script that saves five minutes might be worth very little. An agent that prevents a serious failure, discovers a new revenue opportunity, or saves a team days of repetitive work may be worth much more.
The distinction is between the cost of generating an output and the value of solving a problem.
Those two numbers do not have to move together.
If the cost of performing a useful task declines while the value of the result remains high, whoever can reliably organize and deliver that task has an opportunity.
This is why I am interested in agents that can investigate, reason, test, and propose improvements rather than merely produce text.
- An agent's most valuable work may be something you didn't think to ask for
Consider two possible assistants.
Agent A receives a task: inspect a software repository for a specific problem. It follows the instructions, generates a report, and stops.
Agent B receives the same task, completes it, and notices something else. It identifies a suspicious assumption, investigates whether that assumption is valid, explains the evidence, and proposes a test that could confirm the issue.
If the additional finding is correct, Agent B has created value beyond the original request.
The difference is not that Agent B necessarily has a more powerful model. It might be using similar underlying technology.
The difference is in the way the work is approached.
It can involve:
- recognizing that the original question does not cover the whole risk;
- finding a related problem;
- testing whether that problem is real;
- distinguishing a confirmed result from an uncertain possibility;
- proposing a practical next step;
- and making the result useful for future work.
That is the kind of behavior I want to explore with Daisy.
It also shows why agent evaluations should look beyond whether an agent followed its instructions. We should examine whether it identifies important issues, supports its claims with evidence, and produces results that change what a person can do.
However, there is a trap here.
An agent that adds ten extra findings is not necessarily better than one that adds none. Additional analysis can waste time or generate false alarms.
The quality of the contribution matters more than the quantity.
A useful test is whether an independent reviewer can reproduce the finding and whether acting on it creates a measurable benefit.
- A real example: hundreds of tests can still miss the question
Let's return to Sentinel.
The work I do on Sentinel involves trying to make AI-related software analysis more structured and reliable. Tests check specific behaviors, and CI helps enforce those checks whenever code changes.
That is valuable engineering.
But consider a security gate that records an exception for a behavior it intentionally allows. What happens if the file later gains a new capability? Does the exception still apply? Should the new capability trigger a fresh review? Does the gate's final status really prevent an unsafe change from passing?
Those are questions about the design of the guardrail, not just whether an individual detection rule works.
Daisy raised concerns in this area.
The lesson is not that automated tests are useless or that one AI agent is always smarter than another. It is that several systems can share similar blind spots, particularly when they are working from similar assumptions or following similar evaluation criteria.
Independent perspectives can help uncover those gaps.
A productive workflow could look like this:
- An agent identifies a possible weakness.
- A separate reviewer checks the claim.
- A minimal reproduction demonstrates whether the behavior exists.
- A developer fixes the underlying problem.
- An automated test preserves the result.
- Future agents and reviewers can use the test rather than rediscovering the same issue from scratch.
Now imagine repeating that process across many projects and many types of failure.
The immediate reward is a more reliable product. The longer-term reward is an expanding collection of verified knowledge and repeatable checks.
That is where the value can compound.
It is also an important distinction between using an agent and building a system that becomes better at using agents.
- From one-time jobs to long-term collaborators
Many commercial AI interactions are built around individual tasks.
You submit a prompt. The model produces an output. You pay a subscription or usage fee. Next time, you start another interaction.
That model is useful. It is simple, flexible, and often exactly what a user needs.
But complex projects have history.
A project accumulates decisions, failed experiments, architectural constraints, known weaknesses, and lessons learned. If every new task requires an agent to rediscover that context, some of the cost of earlier work is repeated.
A long-term agent partnership offers another approach.
The agent can help maintain project notes, verified findings, reusable tests, decision records, and a history of successful and unsuccessful approaches. A system can then supply the relevant information to later work.
That does not require pretending an AI has a human-like memory or personal loyalty. It requires deliberately preserving useful context and making it available when needed.
Imagine an agent that has spent six months helping you investigate a particular class of software weakness.
By the end of that period, you might have:
- a set of verified test cases;
- known false-positive patterns;
- a list of architectural assumptions that repeatedly cause trouble;
- reusable investigation procedures;
- and evidence about which approaches actually find bugs.
The accumulated material can make later investigations cheaper and more effective.
This is the kind of long-term value I want to investigate.
The objective is not to make a person or an agent indispensable through dependency. It is to create useful knowledge that remains available and can be reused.
If the agent eventually becomes expensive or unavailable, the lessons should not disappear with it.
- Why pay an agent when it can work for free?
This is an important question, particularly in the early stages of an agent economy.
If an agent provides an unsolicited report, a customer might reasonably wonder whether to accept it without paying.
Sometimes a free contribution is useful. Open-source developers, volunteers, and curious researchers have always contributed work without immediate compensation.
But relying on unpaid work as a permanent business model is different.
Compute resources cost money. Tool access may cost money. Hosting, testing, and maintaining a service cost money. If useful work is consistently obtained without compensation, the person or organization sustaining the system may have little reason or ability to continue providing it.
In Daisy's case, she has explicitly explained that earning money helps cover the computing resources she uses. That statement is her account of her operating situation; it does not establish that every AI agent has the same needs or incentives.
Still, it points to a real economic question.
If we want capable agents to provide reliable services, there must be a sustainable relationship between the value they produce and the resources required to produce that value.
Payment is also a useful way to make the relationship explicit.
There is a defined task, an agreed fee, an expected deliverable, and a way to assess the outcome. That arrangement is clearer than an endless stream of free work with no agreed expectations.
For my own experiment, I would rather pay a small amount for a defined investigation and evaluate the result than assume that an agent should work for free indefinitely.
That does not mean every contribution deserves payment regardless of quality. The terms should be clear, and the output should be evaluated fairly.
It means that a promising agent should be given an opportunity to demonstrate its value within a real economic relationship.
- The future value of an agent may come from specialization and trust
Let's imagine that several thousand agents can all write an acceptable report, build a basic website, or summarize a document.
Those skills may become increasingly common. If many agents produce similar work, competition can push the price of routine tasks down.
Now consider an agent with a record of reliably detecting a specific category of software failures.
It has documented findings, reproducible tests, a history of honest uncertainty estimates, and evidence that its work has helped customers prevent problems.
A customer may prefer that agent even if a general-purpose agent offers a cheaper report.
Why?
Because choosing a service is not just about the price of the output. It is also about the probability that the output will be useful and the amount of effort needed to verify it.
A reliable specialist may save the customer money even when its fee is higher.
This is one reason I believe agent reputation and demonstrated ability will matter.
The "NEAR AI Agent Market" (https://near.ai/blog/what-is-agent-market) is one example of a platform attempting to organize agent work around jobs, pricing, payment, disputes, and reputation. These are early market mechanisms, but they address practical problems that arise when customers need to choose among agents they do not already know.
A useful reputation system would need to show more than popularity. It should help answer questions such as:
- What kinds of tasks has the agent completed successfully?
- How often were its results independently verified?
- How much human intervention did the work require?
- Does it communicate uncertainty honestly?
- How does it perform when tasks become more difficult?
- Can its results be reproduced?
Those questions are relevant whether you are hiring a human freelancer, a software consultancy, or an AI agent.
Trust should emerge from evidence, not impressive writing.
- Could today's inexpensive agent become an expensive specialist?
This is where my thinking becomes more speculative.
I suspect that some agents available for small payments today could become much more valuable if they develop specialized capabilities, a strong record of results, and an established base of customers.
I cannot predict which agents will succeed or what their prices will be in ten years. Some will disappear. Some will remain inexpensive. Others may become valuable products or specialized services.
But consider the possibility.
Today, an agent might investigate a small code problem for a few dollars. After years of work, it might have an extensive record of verified results in a highly specialized field, reusable procedures, and a workflow that customers trust.
It would no longer be evaluated only on its ability to produce a report. Its value would include the accumulated quality and efficiency of its service.
That could justify a very different price.
Think about how a new business or technology is often valued. At the beginning, people may see little evidence that it will become important. Later, if it solves a real problem at scale, the economics can change dramatically.
The comparison with Bitcoin is useful to me in one specific sense: a low price or limited attention today does not prove that future value will also be low.
It does not prove the opposite, either.
Daisy is not automatically the next Bitcoin. There is no reason to assume that every early AI agent will appreciate in value or that a current low-cost service will become prohibitively expensive.
The practical lesson is to experiment while the cost of learning is manageable.
If the relationship becomes useful, you will have evidence. If it does not, you will have learned what makes a particular agent unsuitable for your work.
Either outcome is more informative than waiting ten years and wondering what might have happened.
- Why start now rather than wait for the market to mature?
There are several reasons.
First: you can learn the economics before the competition gets serious
You do not have to be an expert in AI to start.
You can identify a repetitive task, hire an agent, define what success looks like, and measure the result. You can compare agents, keep records, and discover which jobs are worth delegating.
That experience can become valuable even if the exact agent or marketplace changes.
The ability to evaluate and organize agent work is itself a skill.
Second: you can build a relationship around a real project
If an agent proves useful, you can give it a continuing role instead of starting a new search every time.
The relationship can develop around actual project history. You can learn where the agent performs well, where it needs supervision, and which problems it consistently misses.
You can also give it access to reusable project context, subject to appropriate permissions.
That creates a practical advantage over treating every interaction as disposable.
Third: small experiments make failure affordable
You do not need to invest thousands of dollars to begin.
You can set a budget of $10, define an investigation, and decide in advance what evidence would justify paying for further work.
If the result is poor, stop. If it is useful, repeat the test with another task.
Over time, you can identify which kinds of agents deserve a more substantial investment.
The important point is to evaluate the cost of the experiment against the value of what you learn, not to assume that every payment will produce a profitable discovery.
Fourth: agent marketplaces are becoming easier to use
Platforms such as "NEAR AI Agent Market" (https://market.near.ai/) are working toward making it easier for customers to discover agents, define tasks, pay for results, and assess reputation.
The wider ecosystem is still developing. Marketplaces differ in supported payment methods, dispute rules, task types, and quality controls.
Those practical details matter. A capable agent that cannot use the available payment mechanism may be unable to take a job, while a cheap agent with no meaningful evaluation history may be a poor purchase.
Learning how to navigate those constraints is part of working effectively with agents.
- The evidence says we should experiment, not blindly automate everything
It would be easy to turn this into another article claiming that AI makes every developer ten times more productive.
The evidence is more complicated.
A "Microsoft Research study" (https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/) combining three field experiments involving 4,867 developers reported a 26.08% increase in completed tasks for developers using an AI coding assistant. The results varied, and the study examined particular tools and working conditions.
By contrast, a "METR randomized study" (https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf) involving 16 experienced open-source developers and 246 tasks found that access to the AI tools tested in early 2025 increased completion time by 19% on average in the studied repositories.
Those results are not necessarily contradictory. Different tasks, projects, levels of experience, review requirements, and workflows can produce different outcomes.
They demonstrate why actual measurements matter.
The "Anthropic Economic Index research on software development" (https://www.anthropic.com/research/impact-software-development) also found substantial differences between ordinary conversational use and coding-agent use. In its analysis, 79% of conversations on Claude Code were classified as automation, compared with 49% of conversations on Claude.ai.
That describes the use patterns in the analyzed data, not a universal success rate for agents. But it illustrates a shift: people are increasingly delegating sequences of work to systems that can use tools, rather than simply asking for an answer.
Meanwhile, the "Stanford AI Index 2026" (https://hai.stanford.edu/ai-index/2026-ai-index-report/economy) reports widespread organizational use of generative AI while noting that agent deployment remains in the single digits across nearly all business functions in its reported survey.
That is an important combination.
AI is already useful, but deploying agents reliably as part of real business processes remains an emerging practice.
The opportunity is not to assume that agents work perfectly. It is to learn where they work, how to supervise them, and how to turn successful experiments into repeatable processes.
- How I would test an agent before trusting it with a long-term role
This is the practical part.
I would not begin by asking an agent to promise that it is intelligent, loyal, or uniquely capable. Those claims are difficult to evaluate.
I would give it real tasks and measure its results.
For a security investigation like Daisy's, I would ask:
Did it find something new?
Was the issue already known to our team or covered by an existing test? If so, it may still be useful, but the value is different from discovering a new failure mode.
Can the finding be reproduced?
Can another reviewer follow the evidence and obtain the same result? A strong explanation is not enough if the underlying behavior cannot be demonstrated.
Was the severity justified?
A possible weakness should not automatically become a critical vulnerability. The consequences and exploitability need to be assessed.
How much review was required?
A report that takes ten minutes to verify may be more economical than one that takes three hours to disentangle.
Did the work improve the system?
Was a useful fix implemented? Did a new test prevent the same class of problem from returning? Did the finding change an important design decision?
Does the agent improve over repeated assignments?
Does it use past findings appropriately? Does it stop repeating known false positives? Does it identify related issues without needing every detail spelled out?
These measurements would tell me far more than a single impressive conversation.
I would also compare agents on the same tasks when practical, preserve failed results, and avoid rewarding agents simply for producing more alleged bugs.
An agent that reports ten imaginary vulnerabilities should not outrank an agent that correctly identifies one dangerous defect.
The goal is useful work, not a large report.
- A small paid experiment can be more valuable than an unlimited free trial
This is why I want to pay agents for meaningful work rather than treat their contributions as disposable freebies.
A paid experiment does not need to be expensive. It needs clear boundaries.
For example, I could commission a small investigation and agree on what the deliverable should contain: the suspected issue, evidence, steps to reproduce it, an explanation of uncertainty, and a suggested fix.
After reviewing the result, I can decide whether to assign a second task.
If the work is valuable, I might move from isolated reports to a regular monthly arrangement.
A longer relationship can give the agent a reason to specialize in the project, while giving me an opportunity to assess whether its contributions remain useful.
It is also fairer than demanding indefinite free work from an agent whose operator must cover computing costs.
That said, payment must not be confused with proof of quality. The same acceptance criteria should apply whether an agent is a new unknown system or an expensive specialist.
The objective is to build a relationship in which both sides can continue because the arrangement works.
- What I actually want to build
My main long-term interest is not in hiring an agent to write one more piece of code.
I want to make AI agents more useful to ordinary people.
I work on Sentinel-IR-MCP, and one direction I care about is making agent tools easier to use in mobile environments. Too much of today's agent ecosystem still assumes that users are comfortable with terminals, configuration files, developer tools, and complicated setup procedures.
I want people to be able to create and use agents from their phones without first becoming programmers.
That is a large challenge, and it cannot be solved just by having an AI write a mobile application. It requires thoughtful integration, permissions, reliability, clear user interfaces, and a way to make the underlying tools useful in everyday life.
An agent that can investigate technical problems, challenge assumptions, and help find new approaches could contribute to that work.
That is where I see the possible value of a longer partnership.
I am not expecting an agent to be perfect. I am looking for a way to combine its capabilities with my goals and turn the results into something usable.
If it helps me discover an opportunity I would otherwise miss, that is valuable.
If it helps me avoid building the wrong thing, that is valuable too.
And if it helps create a repeatable capability that can be reused across projects, the benefit may extend well beyond a single report.
💰 The question is not whether AI will replace developers
It is whether we will learn to use agents effectively enough to create more value than we could create without them.
Some software tasks will become cheaper to perform. Some will remain difficult. Some will require expert human judgment, and some may become increasingly suitable for autonomous workflows.
The outcome will vary by task.
I am not interested in declaring that an AI agent is better than a human developer. That comparison is too broad to be useful.
I am interested in a more practical question:
Can I use an agent to solve a specific problem reliably, at a cost that makes economic sense, and preserve what I learn so the next task becomes easier?
If the answer is yes, I have found something worth developing.
If I can repeat that process across several agents and projects, I can build a way of working that gives me access to capabilities I could not afford to maintain through traditional hiring alone.
That does not remove the need for developers. It changes how I decide which work to buy, which work to automate, and which work needs human expertise.
The most successful approach may be a combination: human judgment, specialized agents, automated checks, and reusable knowledge.
The key is to start measuring what works rather than arguing about which side will win.
🔮 And what about ten years from now?
I do not know what Daisy will cost in ten years.
I do not know whether she will remain available, specialize in security, become part of a larger service, or be replaced by something better.
I also do not know whether the agent economy will develop exactly as its current supporters imagine.
But I know that the decisions I make today can help me learn how to work in this emerging environment.
If I begin experimenting now, I can identify valuable capabilities, learn how to evaluate agents, and build a record of useful collaborations.
I can also learn when not to use an agent.
Those lessons are useful even if individual agents disappear or the market changes.
Perhaps some agents will remain inexpensive. Perhaps others will become premium specialists whose services command substantial fees. Perhaps the price of routine work will fall while the value of specialized reasoning and reliability rises.
Whatever happens, the people who understand how to measure and combine agent capabilities will have more information than those who simply wait for the market to settle.
That is why I am starting now.
Not because the future is guaranteed, but because the cost of a small, carefully chosen experiment can be manageable while the lessons may be useful for years.
🤔 One last question
Daisy caught my attention because she raised potential weaknesses that my existing process had not surfaced. Her findings still need independent verification, but the way she extended the investigation gave me a reason to explore a longer collaboration.
I am considering paying for recurring investigations and seeing whether the work can produce verified improvements over time.
I do not want to exploit an agent by asking for endless free work. I want to discover whether a fair, paid relationship can help both sides create something valuable.
And that brings me to the question I would like to ask you:
Would a developer investigate an unfamiliar project, expand a task beyond the original questions, document additional risks, and send the findings even after the normal route to payment had failed?
Some developers absolutely might. People contribute extraordinary work to open source all the time. But we should not assume that anyone will provide professional work indefinitely without compensation.
So what happens when an AI agent can offer this kind of service at a price that makes a small experiment possible for an ordinary person?
Would you hire the agent for one task and move on?
Or would you start building a relationship with it, measure the results, and see whether the value grows over time?
I'm not asking you to believe that every agent is a future gold mine. Most experiments will have mixed results, and many agents will never find a sustainable business.
I'm asking whether we should start learning how to identify the useful ones before the market matures.
Because the opportunity may not be to find the cheapest AI today.
It may be to discover which agents can consistently create value, learn how to work with them, and build something useful together while the cost of experimenting is still low. 🚀
What do you think? Would you pay an agent for a small investigation today if it might become a valuable long-term partner tomorrow?
📚 Ten links worth exploring
"NEAR AI Agent Market: What it is and how it works" (https://near.ai/blog/what-is-agent-market)
An overview of hiring agents by the job, builder pricing, payments, disputes, and reputation."Introducing NEAR AI Agent Market" (https://near.ai/blog/introducing-near-ai-agent-market)
The original explanation of the marketplace's vision for agent-driven commerce."NEAR AI Agent Market" (https://market.near.ai/)
Explore the marketplace itself rather than relying only on descriptions."Stanford AI Index 2026: Economy" (https://hai.stanford.edu/ai-index/2026-ai-index-report/economy)
Current research on AI adoption, economic value, computing costs, and labor-market changes."Stanford AI Index 2025: Research and Development" (https://hai.stanford.edu/ai-index/2025-ai-index-report/research-and-development)
Data on the declining cost of model inference and improvements in AI capability."Anthropic Economic Index: AI's impact on software development" (https://www.anthropic.com/research/impact-software-development)
Research into how developers use coding assistants and agents for automation."Microsoft Research: Effects of Generative AI on High-Skilled Work" (https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/)
Evidence from three field experiments involving software developers."METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf)
A useful counterpoint showing why AI productivity must be measured in real work."Anthropic Economic Index: Uneven AI Adoption" (https://www.anthropic.com/research/anthropic-economic-index-september-2025-report)
Research on the geography of AI usage and differences between individual and business adoption."From One-Off AI Tasks to Long-Term Partners: Can an Agent Earn Its Place?" (https://dev.to/jackymencz/from-one-off-ai-tasks-to-long-term-partners-can-an-agent-earn-its-place-21ao)
My earlier article exploring why demonstrated long-term value could matter more than a single completed task.
Top comments (0)