I have been building front-ends since 2012.

I survived the jQuery spaghetti days. I lived through the great AngularJS migration.

Now, as a Tech Lead, my daily reality looks a little different. I spend a lot less time centering divs and a lot more time explaining why a "simple" feature is going to take three sprints to deliver.

Management wants us to ship faster. I agree with them. But I don't want my team to just type faster. I want a system.

So, I decided to change things. I stopped relying on optional chat windows and ad-hoc prompts.

I wired an agentic AI workflow directly into our repositories.

The Blueprint Before the Code

Here is how the setup works.

Every single repository gets its own strict technical rules. Custom instructions, sitting right there in the codebase. When a ticket comes in, a base knowledge LLM agent wakes up. It reads the ticket. It reads the repository's specific rules.

It doesn't just start dumping code. That is a recipe for disaster.

Instead, it writes a plan. It generates a clean Markdown file right in the .github folder.

Then, I step in. Or one of the team members steps in. We read the plan. We tweak the logic. We adjust any missing context or correct the LLM if it misunderstood the architecture.

Only when a human gives the green light the AI generate the actual code.

It sounds amazing. It is an almost fully automated flow from ticket to pull request.

The Hard Truth About Speed

But here is the reality I learned very quickly.

AI will massively increase your code output. It executes at lightning speed. It never gets tired.

But writing code was never our biggest constraint.

Think about your last nightmare sprint. Was it because you couldn't type fast enough? No.

The real bottlenecks are always the same. Defining the actual requirements. Integrating messy, legacy systems correctly. Handling ambiguity. Operating and maintaining that software in production when things go sideways.

If you just introduce AI generated code without a strict structure, you aren't solving problems. You are just scaling them.

You get review overload. You introduce higher operational risks. Security blind spots multiply. You completely lose the context and accountability of why something was built.

In the book Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright, there is a brilliant distinction. They separate "programming" from "software engineering."

Programming is just writing code. Engineering is writing code that survives over time.

AI is fantastic at programming. It is terrible at engineering.

The Shift to "Code, People, Flow"

This is exactly what I mean when I talk about my core philosophy: Code, People, Flow: The Reality of the Tech Lead. You cannot just inject an AI code generator into a team and expect a miracle. You have to fix the workflow first.

Our roles as developers are fundamentally shifting. The days of acting like a human transpiler for Jira tickets are ending.

Now, our job is different.

• Directing the AI.
• Validating the messy outputs.
• Making the hard architectural decisions.
• Ensuring the solution actually fits the business need.

We are becoming editors, not just writers. We need proper governance. We need good access control. Most importantly, we need strong engineering judgment.

The Reality Check

Is this agentic setup a silver bullet?

Absolutely not.

This does not give instant results. It is a grind. It requires a heavy testing phase. It needs continuous measurement and data collection.

Plus, the AI is going to guess wrong. A lot. When an agent misinterprets a requirement, you have to go back in. You update the repository instructions. You tweak the agent's skills. You refine the prompts. It is a continuous loop of corrections.

It is a long term investment.

But it gets us out of boilerplate and back into real engineering. That is the work that will still matter as AI changes how we build software.