Fewer Developers, More Builders (Part 2): The First Week of Going AI-First Project

In my previous post (https://medium.com/@nedvedyang/fewer-developers-more-builders-why-were-starting-an-ai-first-project-2b64aaf3d947), I shared why we decided to start our first deliberately AI-first project , not just building a sales quotation application, but redesigning how we approach the entire SDLC. This week, we actually began. And what became immediately clear is that AI-first development is not primarily a tooling shift. It is a capability shift. The tool may be the same, but the return depends heavily on the person using it.

A huge learning week for the guys , challenging, intense, and super fun….

The Environment Is Only the Beginning

We wired our environment deliberately. Azure Functions with Node.js for the backend. Azure Static Web Apps for the React frontend generated from Figma Make. GitHub Flow for source control. Local development configured properly. Cursor connected to GitHub for branch management , PRs and deployment, integrated with Azure for log troubleshooting, and aligned with design outputs from Figma.

We also tested Claude Code more seriously and were surprised by how much deeper its reasoning could go in certain architectural scenarios. That alone has already triggered internal discussions about whether our default AI interface should evolve. But even with the same setup, the results were not uniform. Different people used the same AI differently. And the outcomes varied accordingly.

AI Is a Force Multiplier — The People Who Use it Matter

In the first few days, we saw a clear pattern. Some engineers treated Cursor like a faster autocomplete. Others treated it like a thinking partner. The difference was visible in the output quality.

When AI was given narrow instructions, it delivered narrow results. When it was given architectural context, constraints, and intent, it responded with structured reasoning. That realization extends beyond prompt phrasing.

If we are operating with trunk-based development, the AI needs to understand that context. If our database changes require migration discipline and versioning control, the AI needs to be guided accordingly. If security scanning and static code analysis are part of the pipeline, we must design prompts and workflows that account for them. AI will not automatically respect your engineering philosophy. You must encode it.

The more mature the developer, the more structured their thinking about branching strategy, database evolution, dependency management, security integration, and deployment discipline, the more effectively they can leverage AI. Conversely, if someone lacks those foundations, AI may simply accelerate inconsistency.

The people who use the tool matter.

One small example early in the week captured the shift better than any architecture diagram. Our team lead assigned a simple task: download a basic Express.js repository, connect it to Azure, and ask Cursor to modify it into a working deployment… Nothing wrong, but we hv a better way of doing it. Instead of micro-managing the sequence, I demoed something different: explain the context. Describe what we are building. Clarify why we are deploying to Azure. State the constraints. In short, communicate intent rather than steps. The result was noticeably better and a lot of efforts were saved. The AI proposed structural changes instead of patch fixes. It reasoned about configuration coherently. It stopped behaving like a script executor and started behaving like a collaborator.

It revealed something subtle but critical: AI-first development is not about issuing faster instructions. It is about providing better context.And the ability to provide context depends entirely on the human.

Security, Discipline, and Flow

One interesting discussion this week centered on when to introduce security testing in an AI-first workflow. Do we rely on the AI to generate secure-by-default code? Do we integrate static code analysis early in the CI pipeline? Do we let AI propose database schema changes freely, or do we constrain it within migration frameworks? These are not abstract questions. They shape whether AI-first becomes chaotic or disciplined. In traditional development, many of these guardrails are enforced by friction. AI removes friction. That is powerful, but it also means discipline must become explicit rather than implicit. In other words, AI-first development requires stronger architectural clarity, not weaker.

Mindset Over Mechanics

Earlier, I wrote about how explaining cherry-picking in Git felt slightly distant from the new center of gravity. This week reinforced that feeling.

The differentiator is shifting away from mastering low-level mechanics and toward orchestrating higher-level systems. But that does not mean fundamentals disappear. It means fundamentals become encoded into guidance, prompts, and workflow design. The strongest contributors this week were not those who typed the fastest. They were those who could articulate constraints clearly, frame architectural intent, and evaluate AI output critically. AI amplifies thinking quality.

Builders, Not Just Developers

If coding becomes increasingly accessible, the role of the developer evolves again. The skill is no longer only in writing syntax or memorizing frameworks. It is in defining boundaries, sequencing complexity, embedding security discipline, and making trade-offs visible. We may see fewer traditional developers over time. But we will almost certainly see more builders. Builders understand systems. Builders think about database lifecycle, CI/CD integration, security posture, compliance implications, and long-term maintainability. AI accelerates their execution. It does not replace their judgment.

This first week mades sth clear: AI-first development will elevate the level at which engineering happens. And that elevation depends largely on the people in the room.

The show is on and we will hv more fun… 🍻🍻🍻