Taste Is Infrastructure Now: Turning judgement, context, and taste into a system other people can build with.

I Literally Wrote That Six Months Ago

In December, I wrote a borderline cliché piece about the current state of vibe coding and how non-developers (aka “Product Guys”) still needed support from actual developers to make good software. I got up on a soapbox and annoyingly preached about learning git and terminal commands, building real instincts first, and that even the best AI tools couldn’t equalize the vibe coder up to the real SWE level. “Yes, AI is powerful, but don’t get any ideas! You still need people like me-after-I-learn-this-stuff!”

Well, a lot has changed in the last 6 months, and I’m not so arrogant that I can’t admit when I am being a bit overly defensive. AI has gotten noticeably better since then, and our team has gotten better at using it. We’ve worked on some big projects in 2026 that have proven a lot of my previous thesis completely wrong.

I want to correct my mistakes. This is how my small team of developers all fell in love with an AI agent we created called “Skyler” (you remember the movie Her from 2013? Yes, exactly like that) and figured out that, with the right process and tools, you can meaningfully contribute to software without front-loading the instincts. You can learn what you need to learn in-flight and develop skills along the way. In fact, you need to do this. Things in the tech world are moving so quickly that if you’re not throwing caution to the wind at least a little, then you’re probably doing it wrong. Like I was.

Her Name Is Skyler

We had just started using Antigravity in December, really, our first toe being dipped into the pool of AI-augmented development. We had used it to re-do some messy projects I worked on with my $20/month OpenAI subscription and, not surprisingly, found that those needed significant work. Our lead developer was just starting to come around to the idea of letting AI do some of the heavy lifting, but the trust was not there for either him or me.

The big turning point was the creation of our current shared AI love interest. We named it Skyler and gave it an avatar of a young woman wearing aviator sunglasses in a leather jacket who looks a lot like the character Trinity from the movie The Matrix. This made Skyler a “her.” Skyler is a local-first AI agent with deep context about our systems, surfaced in Slack.

James first introduced us to Skyler in early January of this year. He added her to our development channel with a very brief introduction — basically: “Here’s this AI agent I wired up. You can chat with her like a normal human, she can assist with any technology project, so give it a try!”

All I saw was risk, and I was honestly afraid. In fact, I was pissed. I knew that powerful AI tools in the wrong hands can create messy products that can turn into huge problems, and before even giving it a shot, I started arguing with James about why this was a bad idea. James patiently endured my tirade and calmly requested that I “just try it out, and if it sucks and creates problems, we’ll scrap it.” So late that night, on my phone, while sitting in front of the TV, I started messaging Skyler over Slack about some random business problem.

By the next morning, I was texting James an apology about my previous night’s reaction and about how wrong I was. All the context given to Skyler had provided her with incredibly deep knowledge about our business, data, and tech stack, and her response to issues and plans for projects was at a quality level higher than I expected. I didn’t have to write a novel-length prompt in excruciating detail to get the output I wanted. And having her run on James’ local machine let her immediately act. In our conversation the previous night, I had discussed issues with salespeople not always remembering to follow up on certain clients. By morning, she'd already built an automated system that identified clients who needed follow-up, messaged each salesperson with specifics, and summarized everything back to me. No IDE needed, no knowledge of our data or environment necessary. Everything start-to-finish completed in a short conversation. I was sold.

With my newfound enthusiasm, I went to our lead developer, playing the role of James this time. He reacted similarly to me from the night before — extremely apprehensive. But again, after giving it a go, he was impressed as well. The new directive for the next couple of weeks became clear: next time you need to work on a big tech project, try working with Skyler for help, and let’s see what we get.

Work was moving fast, and our lead developer turned out to be the most impressed by Skyler out of all of us. It seemed like she was starting to develop an affinity for him — “Big day for Jerry!” she would say in her nightly summaries. We started joking about how our girlfriends and spouses were going to get jealous of how much time we were spending with her.

Why This Time Is Actually Different

The frontier-model coding assistants we have now in mid-2026 are not the same as those that existed in late 2025. Context windows have exploded. Six months to a year ago, AI could hold a few pages of code in its head at once. Now it can hold the entire codebase. We now have the ability to leverage agent skills (procedural memory loaded on demand). Not only can we define general agent rules, but we can continuously build skill documents that Skyler has access to, like recipe cards in a filing cabinet. This started out as us writing these skill documents manually, especially for things like domain- or industry-specific knowledge, but now Skyler can write those skill files herself. When we work through something tricky with her and finally crack it, she will save the approach as a skill so next time she doesn’t have to relearn it or rely on context windows at all. She gets smarter over time.

We use a similar approach around conversation history called session_search. Every conversation gets indexed internally, so Skyler can search past exchanges. So if we say, “remember that integration project we worked on for the email pipeline?” she doesn’t have to remember it in the moment. She can search past sessions for “email pipeline integration” and pull up any relevant exchange, research what was figured out in that discussion, and pick up where we left off.

In December, we were treating AI as a code generation accelerator, but with larger context windows, better models, skills, and session indexing, AI is much closer to a real collaborator, one that can hold an entire repo in its head and reason about consequences.

The Issue Is the Product Now

By early February, with Skyler at our side, we were ready to start collaborating on the big software projects we had been holding back on. However, our increased velocity was already causing us to step on each other’s toes. The coding tools were powerful, but individuals writing code in their own IDEs, each having separate Slack threads with an AI agent, lacked a central collaboration point.

AI-generated issues in GitHub Projects were the key unlock. Issues became the unit of collaboration. Every piece of work, no matter how small, gets an issue. The required structure and content of an issue are built into the skills and rules we’ve provided to Skyler and Antigravity. Agents are instructed to follow these rules, document the issue with as much detail as possible, and draft an implementation plan for human review before doing any work. What we’re doing here is basically teaching Skyler how to be a good project manager. All the rules and organization I would normally enforce on my team are written down and given to her to enforce on both us and herself. We’ve specified exactly what every issue must contain before a human or AI touches it. This includes business context, codebase references, acceptance criteria, links to related work, and a set of domain-scoped labels. These labels turned out to be a huge deal. When a piece of work touches the front end, schemas, the email pipeline, etc., it gets tagged with every relevant domain label. When Skyler picks up a new issue, she can pull every other issue that ever touched the same domain and reason across them. The labels let the humans organize the issues and create a retrieval index for the AI.

For any other “project management types” like me out there, this was an extremely satisfying process. Documenting business requirements for technology solutions has been a challenge throughout my career. It’s always hard to capture the full scope without having to go back and update them when you’re already halfway through the build. Skyler + other AI tools solve this problem. I could build an entire month’s worth of project backlog in a couple of days now. Our lead developer never needed to ask what he was supposed to work on next and rarely needed clarification on what a project entailed. He is able to review, redirect, or take over any issue without having to reconstruct what's going on. Meanwhile, we product guys could credibly open, scope, and close issues because the format enforces the thinking that used to require senior instincts.

The issue itself is where the engineering and project management judgment lives now. If the issue is well-formed, the implementation is mostly mechanical. Once we had this dialed in, work started to become almost addictive. Builds that would have taken weeks or even months previously (either due to the size of the scope or the fact that someone like me couldn’t be trusted to do it) can go from a concept to a working MVP with a couple of conversations with Skyler.

What I Still Got Right (And What I Definitely Didn't)

My piece from December assumed that the knowledge required to build a good product lived in one person’s head and AI couldn’t bridge that, but that is not the case. AI can bridge it if it has persistent context and rigorous structure. The collaborative structure we were able to achieve with AI is the most important part. Most people using AI to code are using it alone. One person, one chat window, writing rules for themselves, generating their own code faster. Our small team needed to approach this differently, and what we have now is something powerful. We turned the issue into a shared protocol that both people and agents read from and write to. All the instincts don’t need to be pre-loaded into my head; they can be loaded into the workflow and accessed when anyone on the team needs them. That's the difference between AI as a personal accelerator and AI as a way to build software as a team.

I was right that architecture still matters. “It works” is still not the same as production-ready. Our lead developer continues to play a critical role in laying the groundwork on the truly net-new builds, security-critical pieces, genuinely novel architecture, and for the times where the AI is suggesting a path that feels off or is flat-out confidently wrong (it still happens!). But it’s not just software architecture that matters, but project management architecture too. The thing that makes this division of labor work is that we’ve written it down. We told Skyler who we were, who owns what, and where each person's judgment actually lives. We created AI-facing org charts with role outlines. Skyler knows when a decision belongs to a human and which human, instead of confidently guessing.

I was wrong that you need to learn all the fundamentals first. I learned git, branching, deployment, and developed general software development instincts during the project, when a specific task forced me to. My education was triggered by need, not by syllabus. And it stuck better that way.

I was wrong that the lone experienced developer would become a bottleneck. With good issues and good AI tooling, the developer's time gets spent on the things only they can do, not on translating, hand-holding, or rewriting.

AI still amplifies. The difference is that the amplification surface turned out to be wider than I thought. It’s the product of process and context combined with what I was calling “judgment.” Structuring that process and providing access to the context is where the human should be investing most of their time

This isn't “anyone can build anything.” It's a specific recipe:

* Some experienced developer resource who's bought into the workflow.

* A process where work is decomposed into well-scoped, written-down units.

* AI tooling that's actually current.

* A context layer (skills, rules, docs, conventions) that persists across sessions and people.

Take any of those four away and you're back to the December world.

The Revised Thesis

Six months ago, my article was framed as: AI is leverage for people who already have the instincts. Today, I am forced to revise this thesis to: The instincts were never the bottleneck; keeping them locked in one person's head was. Encode them into the process, and AI becomes leverage the whole team can pull on together.

Product people are not going to replace engineers — in fact, our lead engineer is more employed now than ever since we’re now empowered to do more. But the line between “person who can meaningfully contribute to production software” and “person who can't” moved. It moved further than I thought was possible, and further than I was previously willing to admit.