AI-First Engineering: My Experience Building with an Agentic Workforce

I built the first version of my AI-native CRM without consuming an agentic workforce, except for a few simple coding tasks. The feedback I received on the first MVP made me rethink what I was building and, more importantly, how I was approaching the problem.

Who else can better understand the challenge of making that shift than a product engineer? A change in product direction does not stop at changing a few screens. It touches UI and UX, system components, databases, implementation, and all the context switching that happens across engineering while the product itself is still evolving.

This time, I took a different approach. I spent considerable time thinking through the product, how it should be shaped, and the direction it needed to take before getting into implementation.

Once I had clarity, I started with the high-level design and went into the granularities of implementation. I owned the what and why of the problem, and much of the how was delegated to a digital workforce.

That became the beginning of my AI-first engineering experience.

Building a Digital Workforce

The first thing I had to change was how I thought about AI in the development process. I did not want to use an agent simply as another coding assistant, where I would ask it to implement something and then move on to the next prompt.

I wanted to create a workforce that could take responsibility for different parts of execution. The workforce had defined roles, instructions, skills, and responsibilities, with an orchestrator and a tech lead coordinating the work.

The Workforce

The workforce I created consisted of:

1. Backend Engineer: Responsible for backend implementation, with an emphasis on structured and modular code.

2. Frontend Engineer: Responsible for frontend implementation, navigation, state management, and backend integration.

3. Designer: Responsible for designing features based on requirements, product context, branding, and design guidelines.

4. DevOps Engineer: Responsible for infrastructure, libraries, containers, databases, and the environment required for implementation.

5. Code Reviewer: Responsible for reviewing the implementation against defined engineering rules.

6. Tech Lead: Responsible for creating the plan, driving execution, and reviewing the completed work.

Each agent had a defined responsibility rather than being given the entire problem.

The workforce was also supported by specific instructions and skills. The designer had UI instructions, the frontend engineer had web-specific instructions, the DevOps engineer had operational instructions, and the backend engineer had instructions around the core APIs. Skills such as API contracts, Firebase authentication, Go, Next.js, PostgreSQL, and UI/UX design were provided where they were relevant.

The objective was not to create more agents for the sake of having more agents. It was to create boundaries around responsibilities so that each agent could operate with the context and capabilities required for its part of the work.

What I Gave the Workforce

Once the workforce was created, the next question was what I should give it.

I quickly realised that the quality of the output was strongly influenced by the quality of the input. The workforce could execute a well-defined problem, but I still had to provide the context required to understand where that problem belonged within the larger system.

For a feature, the inputs included the requirements document, backend logic, API endpoints, high-level specifications, a feature-specific ER diagram, and a sequence diagram. At the top level, the workforce also had the system design, the broader ER diagram, branding, and information about the product.

This was very different from simply saying, "Build the onboarding feature."

I had to think through the feature before handing it over. That included understanding the user journey, the database relationships, the APIs, the sequence of actions, the libraries involved, and how the feature would affect other parts of the system.

The more I worked this way, the clearer the distinction became. The workforce did not need me to describe every line of code, but it needed me to be sufficiently precise about the problem, the boundaries, the expected behaviour, and the surrounding system.

What Happened in Practice

The onboarding feature became one of the first useful examples of how this approach worked in practice.

The workforce took about 2 hours to take the feature from design through implementation to deployment-ready output. It included more than 80% unit test coverage, API documentation, and code review.

I compared that with how I would normally approach the same work with a conventional engineering setup. My estimate was around 2 weeks with at least 6 people: one designer, two backend engineers, two frontend engineers, and one architect, covering design, coding, testing, database schema, infrastructure, documentation, code review, and the discussions required to move the work across those responsibilities.

That is roughly 12 person-weeks of effort.

My own approach took almost one week of focused thinking and documentation, followed by about one day to create the workforce and execute the implementation. I worked through the product and system details before the execution started, while the workforce carried much of the implementation load.

I am not treating this as a formal productivity benchmark. The comparison is based on my own experience and estimate, and a human team brings collaboration and other forms of value that are difficult to quantify.

What mattered to me was the change in where my effort went. I spent less time carrying the implementation and more time thinking through the product, the user journey, the architecture, and the quality of the solution.

What I Owned

I owned the complete product other than much of the execution part. The workforce helped implement my thoughts and solutions, but I remained responsible for the design, decisions, direction, and outcome.

This meant thinking through the system to whatever breadth and depth was possible before handing the work over. I had to define the product behaviour, system design, data relationships, APIs, sequence of actions, constraints, and scenarios rather than expecting the workforce to discover all of them during implementation.

For example, a requirement such as "I want an onboarding feature integrating Firebase with Gmail and email, with the backend schema and APIs ready" is enough for an agent to start working. It is not enough to communicate the complete product vision behind onboarding, how it fits into the rest of the product, or the decisions that will shape the quality of the implementation.

The agent can execute the solution, but the quality of that solution depends heavily on the clarity of the thinking behind it.

What I Gained

The most useful thing I gained was time to think.

With execution delegated, I had more space to think about the product rather than constantly moving between product decisions and implementation. That thinking was not limited to strategy. I could spend more time on the granularities of user experience, relevance, sequence of actions, architecture, system design, ER diagrams, sequence diagrams, API structure, and the interactions between different parts of the system.

There was another effect that I did not initially expect. Working with agents pushed me to become much more specific and descriptive because vague thinking that may work in a conversation with another engineer does not always translate into a reliable instruction for an agent.

That forced me to think harder about what I actually wanted the system to do. Instead of thinking only in terms of high-level steps, I found myself understanding the deeper user journey and the details between those steps.

The workforce therefore gave me more than execution capacity. It gave me more room for product thinking, system thinking, and decision making.

The Workforce Is Not a Silver Bullet

The experience also made it clear that an agentic workforce comes with its own constraints and challenges. There are places where agents perform extremely well, and there are places where I still have to sit with the problem, understand what is happening, and polish the result.

One of the biggest lessons was around context. Agents are excellent with small, specific tasks and clear instructions, but simply increasing the size of the prompt does not necessarily improve the result. Large context works when it contains the right information within the right boundary; when multiple responsibilities and unrelated concerns are mixed together, the additional context can actually misguide the agent and reduce the quality of the output.

The same principle applies to delegation itself. I do not need to invoke an agent for every problem, particularly when I already understand a small bug or a local issue well enough to debug and fix it myself. In those situations, an agent can be more useful as a reviewer that examines the changes and checks for side effects rather than taking ownership of the entire fix.

There is also a practical prerequisite to this model. I do not need to be an expert in every programming language the workforce uses, but I need enough coding knowledge to understand the implementation, reason about the architecture, review the output, validate the scenarios, and fix problems when required.

Agents can take execution responsibility, but I still own the review and the outcome.

The Tools Matter as Much as the Instructions

One of my most expensive lessons came from a very simple assumption. I assumed that if an agent could read files, it would naturally be able to write files as well, so I did not explicitly provide the write tool.

The agent could understand the work that needed to be done but could not perform the final action. Instead of stopping, it kept delegating the work to other agents with increasingly large prompts, and the agents repeatedly went through analysis, planning, drafting, attempting to write, discovering that they could not write, and passing the work to another agent.

That loop consumed about 2 hours and $5. The problem was not that the model lacked intelligence; the workforce simply did not have the capability required to complete the task.

That experience changed how I think about agent design. The right instructions with the wrong tools are still the wrong system, and a sophisticated prompt cannot compensate for a missing capability.

The agent needs the tools required for its responsibility, just as a human engineer needs the environment, access, libraries, and systems required to perform the work.

Agents and Innovation

There is another boundary that I have become more conscious of while working this way.

An LLM or agent can reason over context, identify patterns, generate alternatives, and produce very strong implementations. But its ability to work on a problem is still shaped by the information, context, and patterns available to it.

If I want the product to solve a problem differently, I still need to provide the direction. The product vision, the customer problem, the broader system implications, and the decision about what should exist are still things I need to own.

The agent can help me explore an idea and can sometimes produce something that triggers a better idea in my own thinking. But I do not see that as a reason to delegate product thinking itself.

The Economics of AI-First Engineering

The economics of this approach are interesting because the benefit is not simply that an agent costs less than a human engineer.

An agentic workforce can actually become expensive when it is used ineffectively. Large prompts, unnecessary delegation, repeated execution, poorly configured tools, and agent loops can consume significant tokens and time, and can make an agentic workflow more expensive than the human effort it was intended to replace.

My own experience with the missing write tool was a small but very real example of this. Two hours and five dollars were spent without producing the intended result.

Where the Leverage Comes From

The economics improve as the workforce improves.

I learn which tasks to delegate, refine the prompts, improve the tools, establish better boundaries, and understand where agents perform well and where they need stronger supervision. As those things improve, the same workforce becomes more effective for future development.

There is also a less visible part of the economics. Conventional engineering requires people to spend time moving between responsibilities, explaining requirements, coordinating across disciplines, waiting for dependencies, reviewing implementations, and switching contexts between different parts of the system.

An AI-first workforce can absorb a significant portion of that execution and coordination load.

AI-First Is Not Cost Cutting

For me, AI-first engineering is therefore not primarily a cost-cutting exercise.

The more interesting value is engineering leverage. If AI can take more of the execution load, the engineer can spend more time on product thinking, architecture, system design, decision making, and the quality of the outcome.

That does not mean human effort disappears. Review, testing, validation, debugging, and product decisions remain part of the work, just as they are in conventional development.

The difference is where that human effort is concentrated.

What AI-First Is Not

There are a few things I would not call an agentic workforce.

It Is Not a Magic Wand

A regular PRD is not a complete product specification.

If I simply give a PRD to an agentic workforce and expect a finished product, I am likely to spend a significant amount of time correcting assumptions, adjusting the implementation, and reworking the output. The missing work between the requirement and the implementation is still product thinking, system design, architecture, and engineering judgement.

An agentic workforce is a structured approach where execution can be delegated while the complete solution remains owned by the engineer.

It Is Not a Parallel Programmer

This is also different from the coding assistance and code completion available in modern IDEs.

Those tools can make an engineer faster, and they are useful, but they primarily accelerate work within the existing engineering workflow. An agentic workforce changes the distribution of the work itself by allowing larger pieces of execution to be delegated across specialised responsibilities.

The difference is not simply that more code is generated. The engineer is now designing the work, defining the context, orchestrating the execution, reviewing the result, and owning the outcome.

It Is Not Another All-Rounder Employee or Team

An agentic workforce also cannot simply be managed like a human engineering team.

You cannot distribute product development across agents in exactly the same way you distribute it across an agile team. Agents have their own limitations, context requirements, tool dependencies, and failure modes, and the work needs to be structured around those characteristics.

The workforce is useful precisely because it can be designed around those constraints.

It Is Not a Silver Bullet for Software Development

Agents are very good at writing code because coding is structured work. It follows languages, frameworks, algorithms, constraints, APIs, and established patterns, which makes it particularly suitable for machine-assisted execution.

But building software is larger than writing code.

The product needs to understand the customer and the problem. The system needs to be designed across its components, data, interactions, and constraints. Someone needs to make the trade-offs, understand the broader context, decide what should be built, and determine whether the result actually solves the problem.

An agent can write the code. It cannot build the product.

The Gist

I started this journey by trying to rebuild my CRM after the first MVP forced me to rethink the product and its direction.

The second time around, I changed not only the system I was building but also the way I was building it. I spent more time thinking through the product and the architecture, created a workforce for execution, and delegated a significant part of the implementation while retaining ownership of the decisions and the outcome.

The most important learning for me is that AI-first engineering is not about removing the engineer from the development process. It is about increasing the leverage of the engineer by moving more execution into a workforce while keeping product thinking, system thinking, judgement, and ownership where they belong.

I am still building the complete system.

I am still responsible for what gets built, why it gets built, how the system is shaped, and whether the result is good enough. The difference is that I now have a digital workforce that can help turn those decisions into a working system.

It can write the code, but it cannot build the product.

Contact

+91 - 9738482563

nagaraj.basarkod@yahoo.in