Vertical vs horizontal: How I Actually Build with AI Right Now

Is This Thing On?

It has been a minute since I wrote here. Quick reset. I spent a year in a Fortune 500 executive role and it was not my thing for where I was/am in life at the moment. For the last 15 months I have been hands on again, leading half of a digital commerce engineering org with a partner who runs the other half. I still manage people. I still sit in tons of meetings. The difference is I am on the keyboard every day. It has been the most fun I have had in a long time, and it landed me in a very specific groove with AI.

Why I am writing again

A few months back a good friend reached out. We worked together at Blackboard for almost 11 years and have known each other for more than 20. We both departed Blackboard around the same time (circa 2013-2014). In the last decade we only connected a couple of times by phone or email, but we are the kind of friends who pick up right where we left off. We talked about work, family, and what the last ten years did to us. It was one of my favorite conversations in a long time.

Before we wrapped she asked why I had not posted here in over a year. She said she reads my stuff and wanted more. She told me to get back to it. That nudge stuck with me.

Weeks later I was doing training at one of our stores and I ran into her in person. Total accident. It reminded me that I had promised to write again and had not kept it. So this post is me keeping a promise. It is also a snapshot of the AI journey I am on.

The vertical stack: VSCode, Copilot and MCPs

When I am working a single ticket with clear boundaries I open VSCode and live in a tight loop. The vertical stack is simple, fast, and opinionated. I use a few MCPs to plan the work, check my assumptions, and keep me honest with tests. Copilot is there as a lane assist, not an autopilot.

What this looks like in practice:

• Scope is small, risk is low, requirements are crisp

• I run a short planning session with an MCP to outline tasks, define acceptance checks, and confirm dependencies

• I write the code myself. I am faster on small assignments than Copilot is. When I get stuck I ask Copilot to suggest a diff or a pattern

• I lean on MCPs to validate, verify and test. I assess the result with the same MCPs to confirm I met the requirement

This flow lets me finish without ceremony. My complaint with Copilot at this level is simple. It tries to be helpful by generating a lot of code. On small problems that feels like over engineering. I would rather ship the cleanest change that passes all of my checks/tests.

The Horizontal Stack: Claude Code with N Agents and a Pile of MCPs

The horizontal stack turns on when the problem is big, murky, or outside my comfort zone. If the README is weak, the setup is messy, or the domain is new, I switch to Claude Code and spin up agents. Each agent is a pseudo SME with a clear charter. One agent studies the repository and maps the setup steps. One agent scaffolds the environment and scripts. One agent does PR prep and runs Sonar. Another builds, runs tests, and kicks Playwright if we have coverage.

I use Claude Code more freely for environment work. If the setup spans several tools or there are pitfalls I do not know, an agent can grind while I stay focused on the next decision. I read what Claude produces. I ask/look for teachable moments. I treat my AI sessions like an efficient tutor that explains what has changed and why.

On challenging efforts, I will chain agents for a full loop:

1. Plan the work with explicit outcomes and risks

2. Stand up or repair the environment

3. Make the change on a short lived branch

4. Run unit tests and Playwright where possible

5. Open a PR, request a deep review, and surface Sonar findings

6. Tidy the diffs, write the notes, and merge

This is not about letting an LLM do my job. It is about building leverage when my knowledge is thin or the cognitive load is high. I reach for Claude Code when I need coaching or when the problem space is wide and unclear. Basically, I’m a huge fanboy of Claude Code. It’s not only a great executor of solving a problem, but it’s an incredible teacher.

Planning mode and the code firehose

I like planning mode. I am fine with Copilot or Claude generating or refactoring code across a repo. That is not the issue. The issue is volume. Too much code shows up too fast. Planning mode helps me slow the vibing session down. I ask for a plan, tests, risks, and rollback steps before any changes. That reduces the firehose…aka that intense cognitive load. It also makes the generated work feel intentional.

Context beats chat

I spend a lot of time building agents, commands, and context files. I do not see enough engineers invest here. Most people chain prompts and ask the model to help with X. They treat every session like a new conversation. They rarely front load patterns, standards, and requirements. That leaves the model to guess. I can’t say it enough to my colleagues…your LLM is not Google, so stop treating it like that.

I do the opposite. I keep context files for core languages and frameworks, design patterns, naming conventions, and repo norms. I keep context for testing, performance, scalability, security, infrastructure, automation, accessibility, design and UX, and forensic engineering. I paste or reference these when I start a session. It raises the floor on quality. It reduces the back and forth. It also makes the output feel like code our team would write.

My Current MCP Roster

I use MCPs in both stacks (vertical and horizontal). The short list that keeps paying off for me is Atlassian, Playwright, GitHub, SonarQube, Grafana Tempo, Figma, BrowserStack, and Maestro for mobile testing. I often run two or three in a row to decompose a requirement, capture derived requirements, and sketch a plan. I also chain them during review. For example, I might take the Playwright MCP to execute some tests, SonarQube to annotate smells, GitHub to propose a minimal diff, and Atlassian to push the notes back to the ticket.

Orchestrator Mode

A good session has tempo. I like to vibe when ideas are flowing, then slow down for inspection. There are moments when the model races ahead and I stop absorbing the details. When that happens I shift to a more interactive prompt chain. Smaller steps, clear checkpoints, etc….I ask for diffs with justifications. I ask for a test plan before code. I make the model show its work.

This is not a control thing. It is about staying present in the problem. If you hand everything to your LLM you miss the learning. You also miss the errors that would have jumped out at you if you had been engaged.

AI Can Produce a Lot of Slop

You have probably seen this pattern. A teammate writes a loose prompt, points it at a JIRA ticket, and a few minutes later a PR shows up. No context files. No constraints. No test plan. Maybe a wall of changes that look helpful, but nobody can say if it solves the business problem. A new colleague of mine calls this “AI slop”. Work on a ticket…do a little AI prompting…produce a ton of slop that nobody wants or needs.

I really want my teammates using AI. I also want them to have problem ownership. If your name is on the PR you should know what changed and why. You should be able to defend the choices implemented and speak to the risks. LLMs are incredible powerful, and they amplify the intent of the operator. Remember…You have to be the operator.

Choosing the stack

A simple rule set helps me decide which stack to use.

• If the ticket is clear, the change is contained, and the risk is low, use the vertical stack. Keep the loop tight in VSCode. Let MCPs plan, validate, and verify. Use Copilot for nudges not floods

• If the problem is complex, the domain is new, or the environment is shaky, use the horizontal stack. Create agents as SMEs. Assign setup and review to the right agent. Chain work with short hops and hard checks

• If I feel cognitive overload, switch to Claude Code even on a smaller task. Ask for a teachable moment. Read the notes. Level up

• If I am moving fast and the code feels obvious, stay vertical and keep momentum

Why this works for me

I like the feeling of being the orchestrator. I am constantly building context files and agents. I set constraints in my markdown files. I bring tools into the session that push on different parts of the problem. I also keep my head in the vibe loop so I can explain the result to a teammate or a product partner. That is our job right?

The other reason is a little more personal. I love that I get to commit and be closer to the code. I get to grow my people by pairing with them on real problems. My 1:1s look different now. We talk about prompting, context engineering, and MCP coupling. We run live sessions and review the output. It feels like the early DevOps days but on mega steroids.

Final thought

I owe this post to my friend (Meaghan D.) who reminded me to show up. The AI part is the fun part. The human part is the reason. If this helped you, thank her. If it nudged you to try a new stack or to write again after a long break, even better. I will share my context file templates in a future post.

See you in the next post.