Do we actually 'need' agents?
Do they provide an Orchestral or Managerial experience?
Since early 2025, AI companies have not shut up about Agentic AI. The concept of an omniscient AI model becoming your personal assistant is delightfully sci-fi, and has been brutally difficult to construct. It seems like companies have been trying, and consistently failing, to package this technology within consumer products in ways people see value in.
I’ve spent a non-insignificant amount of time critically evaluating the latest Machine Learning technology and techniques. I’ve been quite clear in my coverage that a not-so-significant portion of the tech industry is leaning on excitement rather than a rational assessment of capability. So naturally, I don’t get excited about new AI technology very often.
Agentic Software Development broke this pattern.
What could this be?
Imagine for a moment that you had a choir of small, local, and highly specialized AI models at your disposal, which you could conduct to your liking. One model could specialize in writing unit tests, another might excel at general code review, and another could optimize data structures for efficiency.
For the first time in a long time, I see adoption of machine learning technology that actually leverages foundational principles of AI. Here’s what I mean:
Agents allow for models to be highly specialized. An orchestra of agents implies many specialized models. I’ve mentioned that AI models work best when they’re individually and selectively specialized. A team of accurate, lightweight models can work far more efficiently than a heavy, energy-inefficient one.
Agents allow for an expanded model context. Having multiple local models allows the user to grant access to far more than can be given through a browser window. Agents can interact with applications on your computer, maybe even do menial tasks for you (reliability may vary). This may suggest more practical implementations than standard GenAI use cases.
Agents can increase efficiency in your workflow. Current software engineering workflows can be slow when you’re working with a smaller team. Agents specialized in specific software development subcategories can help solo developers act efficiently when building complex programs. (I haven’t explored many use cases outside of software engineering, though I’m sure that valid ones do exist.)
Agents can localize your AI experience. AI companies are currently dependent on owning your model context. They capitalize on using our data to generate revenue with no benefit or credit to the consumer. When you run these models locally, all information shared stays on your device, effectively securing your data. This may entice companies into building better products to push users to return to their platforms.
These are just a few of the logical reasons why this technology intrigues me. However, no logical reason could be as exciting as the picture painted by many champions of this technology: the symphonic dream of directing a legion of agents towards completing the world’s most meaningful work. A swarm of agents running on Gigawatts of compute power is directed to analyze mammograms until we find the cure for breast cancer. Without exaggeration, an Orchestral masterpiece of technology.
Why an Orchestra?
The ‘orchestra’ analogy isn’t something I made up. This is the analogy I have most commonly used to communicate why this technology is so transformative.
Ever since the origin of software development, programming has been an intricate, technical practice. To create good software, programmers historically benefited from an in-depth knowledge of computer processes. This has led to a culture of specialization within the industry. The best software developers were the ones who knew a hell of a lot about a particular area of computing.
This obsession with technical mastery is not too dissimilar from classical music.
Classical music as an art form rewards those with in-depth knowledge of music theory. Instrumentalists permitted to play in an orchestra are often those at the top of their field, known for their technical mastery of a particular instrument. The flute is sonically and technically distinct from the cello, as is the piano from the xylophone, as is the tenor saxophone from the alto, and so on. Each is distinct with its own part to play, but they combine in an orchestra to create this incredible concoction of sounds we call an arrangement.
Atop all performers in an orchestra sits the Conductor. Traditionally, an expert in multiple, if not all, areas of instrumentation, the Conductor directs each element to form the ‘correct’ arrangement. The Conductor potentially plays the most pivotal role, as without direction, a symphony would be nothing but a collection of noises. They are also respected as masters of the craft in a way that an instrumentalist can’t attain without composing or conducting music.
Most importantly, the conductor is essential. An arrangement can miss elements and still stand on its own. You can have a beautiful piece without some subcategories of instrumentation, but without the conductor or the arrangement, there will be no music. I think this is the key to understanding the hype behind agentic programming.
I think the software development community is concluding that they need to become essential to keep doing what they do. The old world prioritized specializing to stay valuable, and this new one transforms that specialization into a liability. In a world where so much can be automated away, the only true way to stay secure and grow is to attain a level of ‘mastery’ that AI can’t reach.
The problems start to arise when you conflate mastery with management.
Programming is not an Art
Leading an AI team does not make you a conductor. At best, you’re a manager. Much less romantic, isn’t it?
Agent orchestration doesn’t require you to have an in-depth understanding of every area of software development. One look at Google’s ADK (Agent Development Kit) documentation is enough to prove this technology isn’t aimed at experts. This tool is meant to enable smaller teams to accomplish more.
I could honestly write another 500 words on the false dichotomy between a conductor and an agentic orchestrator, but I don’t think that’s needed. You know software development isn’t art, and you know that it doesn’t require the same dedication to computing that conducting requires to instrumentation and music theory. I think it’s incredibly interesting that this is what the industry has decided to latch onto, and there seem to be interesting implications within. However, none of this changes my excitement about Google’s ADK and getting to use it.
That begs the question, why do this as opposed to programming normally?
Jack of all trades, Masterful headache
Programming is hard. It’s repetitive, mentally taxing, time-consuming, monotonous, syntactically unforgiving, and lots of other words I found in my thesaurus. Building a complete piece of software is a long and arduous process involving dozens of intricate steps all buried within each other.
I asked Google Gemini to ‘generate me an exhaustive list of aspects of Software Development’. Here’s the output:
Requirement Analysis: Gathering and documenting what the software needs to do from a business and user perspective.
Feasibility Study: Assessing whether the project is technically and financially viable.
Project Management: Choosing a methodology (e.g., Agile, Scrum, Kanban, or Waterfall) to manage timelines and resources.
Product Roadmap: Defining the long-term vision and specific milestones for the software’s evolution.
System Architecture: Defining the high-level structure of the software, such as Monolithic, Microservices, or Serverless.
Database Schema Design: Planning how data will be stored, related, and indexed (SQL vs. NoSQL).
API Design: Creating the interfaces through which different software components or external services communicate (REST, GraphQL, gRPC).
UI/UX Design: Crafting the User Interface (visuals) and User Experience (flow and usability) to ensure the product is intuitive.
Frontend Development: Building the client-side interface that users interact with directly.
Backend Development: Implementing the “under-the-hood” logic, server-side processing, and database management.
Version Control: Managing code changes and collaboration using tools like Git.
Environment Configuration: Setting up development, staging, and production environments.
Unit Testing: Testing individual components or functions in isolation.
Integration Testing: Ensuring that different modules or services work together correctly.
User Acceptance Testing (UAT): Verifying with end-users that the software meets their needs.
Automated vs. Manual Testing: Balancing speed (automation) with the human touch for complex edge cases.
CI/CD (Continuous Integration/Continuous Deployment): Automating the process of merging code and pushing it to production.
Infrastructure as Code (IaC): Using scripts to manage and provision server resources.
Containerization: Packaging software and its dependencies into units like Docker containers for consistency across environments.
Cloud Orchestration: Managing containers and services at scale using tools like Kubernetes.
Security Auditing: Identifying vulnerabilities such as SQL injection or Cross-Site Scripting (XSS).
Data Encryption: Protecting sensitive information both at rest and in transit.
Compliance: Ensuring the software follows legal standards like GDPR (privacy), HIPAA (healthcare), or PCI-DSS (payments).
Monitoring & Logging: Tracking system performance and errors in real-time (e.g., using ELK stack or Prometheus).
Technical Debt Management: Periodically refactoring code to keep the codebase clean and maintainable.
Patching & Updates: Releasing fixes for bugs and security holes.
Scaling: Adjusting the system to handle more users or larger datasets.
Technical Documentation: Explaining the codebase and architecture for other developers.
User Documentation: Creating manuals, FAQs, or help centers for the end-users.
API Documentation: Providing clear instructions on how external developers can integrate with your system.
While much of this output isn’t required for every coding project, almost every project requires you to undergo at least half of the processes listed.
To make a fully functioning application just for personal use already requires you to wear a dozen different hats, each of which can take years of study to fit properly. If you wish to publish your application or host multiple apps that interact with each other, prepare to start practicing your balance.
All of this can be overwhelming for one person, which is why software companies have operated with large teams since software engineering became an engineering discipline. While good for the industry at large, I believe this has put off many solo developers and small teams from attempting to make applications at a certain scale. This can function as a form of monopolization, restricting the availability of competitors in the market. I think this technology can even the scales.
Modern Self Sufficiency
This industry has prioritized the ability to move quickly for years. From software development style to company organization structure, tech-focused people have yearned for the ability to make new things quickly. I am no exception, within reason, of course.
Technology like this can enhance the workflow of smaller teams, giving them the bandwidth to compete with much bigger players in this space with far fewer resources. It also gives the big guys the ability to take even bigger shots and stress far less about the ones that miss. I think this is exactly how this technology should be applied.
The bottom line is I’m now able to do more with what I already own. That’s what excites me. I’m able to build more complex ideas, test them without a massive team, and deploy them without being gouged by a monopoly. That’s a world where technology is being used to empower people to create, and that’s exactly where I want to be amongst all the shifting landscapes and monopolistic corruption.
(As with everything, there exists a negative side to the democratization of this technology. But before I research and utilize this technology more, I thought it important to document my excitement and why I felt it.)