Making Software Processes Semi-Autonomous with Agents — My Experiences and the System I Built

Recently, while I was heavily using AI agents in my development processes, I noticed a recurring problem: tasks that required repetitive but detailed context-setting.

Every time I wanted to delegate one of these tasks, I would open a new conversation, provide lengthy context, and repeat the same explanations. While getting the work done took seconds, explaining it took minutes.

This bottleneck pushed me to build an agent skill architecture.

The Root of the Problem: Prompt Repetition and Knowledge Fragmentation

Agents don't know the project context by default. You need to tell them:

• the project architecture
• coding standards
• commit conventions
• testing strategies
• naming conventions

every single time.

Initially, I tried putting agent folders inside the project (.claude, .cursor, etc.). But this approach had three major problems:

• Each project required separate skill definitions
• When a new developer joined, files had to be transferred
• Skills diverged into different versions across projects

This was not sustainable.

The Solution: Converting Agent Skills into MCP Tools

To solve this problem, I built a structure I called agent-skills-mcp.

The idea was this:

Instead of keeping skills in the agent's local folder, I started serving them as MCP tools. These tools are not functions that write code — they are functions that provide guidance.

As a result:

• The agent is defined only once
• All developers use the same skill set
• When a skill is updated, everyone automatically gets the latest version

The Second Problem: Cross-Project Blindness

There was another thing agents couldn't access by their nature: other projects.

For example:

• Taking a component from another project while developing UI
• Examining another service's API structure during backend development
• Referencing shared library code

Since the agent couldn't see these, I had to explain them every time.

The Solution: Corporate Code Memory with Filesystem MCP

To solve this, I gathered all company projects under a single root folder and connected a filesystem MCP to the agents.

But the critical point is this:

This way, the agent can:

• see dependent projects
• read other services' code
• write code to another project when needed

In other words, the agent is no longer an entity that knows only one repo — it becomes an entity that knows the organization's code map.

Third Phase: Managing Processes Without Leaving the IDE

In the next step, I wanted the system to not only write code but actually get work done. For this, I connected agents to these systems:

• Jira
• Slack
• Jenkins

The workflow now operates as follows:

• I create a task in Jira
• I add technical details + a prompt to the task description
• I give the task to the agent

1Do task DEV-1234 in Jira

The agent:

• reads the task
• writes the code
• runs the tests

Then I say:

1Commit, push, and deploy to the test environment

After deployment starts:

• Notify the PO via Slack

The entire process is completed without leaving the IDE.

The Emerging System: Semi-Autonomous Development

With this architecture in place, the following happened:

• The need for repetitive prompt writing was eliminated
• Corporate standards were applied automatically
• Cross-project knowledge barriers were removed
• Operational processes were delegated to the agent

As a result, the software development process went through the following evolution:

• manual
• assisted
• semi-autonomous

The Most Critical Gain

The biggest difference is not speed.

Code is now written:

• not based on the individual developer
• not based on current trends
• not based on experience level
• according to a single centralized intelligence

And this ensures:

Conclusion

Seeing agents only as code-writing tools means missing out on enormous potential. The real breakthrough happens when you turn them into organizational memory and process engines.

At the point I've reached today, I can clearly say:

And this is just the beginning.