Mike’s Blog
All Posts
No. 1
June 30, 2026
The Start of Something New
A few months back, I decided to jump full into AI-enabled coding. One thing I’ve noticed is an absence of pragmatic advice on how to adopt and use AI effectively. As I look to social media, blogs, tech articles, and other sources, most content can be broken into two buckets: evangelists who think this is going to revolutionize the world or skeptics who demonize how destructive or useless it is. What about something in the middle?
Over the course of 12 weeks, I’ve been using Claude Code to build several solutions. Including one solution which is over 200k lines of code. As this phase of coding comes to an end and I transition to company building, I’ve been reflecting a lot on what I’ve read, what I’ve experienced, and what the future might look like.
With that said, I thought I could bring a pragmatic voice to the conversation by sharing reflections, lessons learned, and insights from the experience. Over the next 7 weeks, on Tuesday around 10am est, I intend to release a post focused on a topic I’ve been thinking about in hopes that it will help others navigate the new AI world. I hope you will come along for the journey and would love to hear your thoughts.
No. 2
July 7, 2026
The AI Coding Paradox: Double the code, same velocity.
Target Audience: Engineers, Product/Project Managers
One of the biggest questions I ask myself and see debated online is whether AI code assistants increase productivity. I think it’s a complex and nuanced subject and I can only contribute my anecdotal evidence to the conversation. We’ve all seen the studies, most people are seeing a 4-20% increase in productivity, which isn’t much.
As I previously mentioned, I wrote 200k lines of code (LOC) in about 10 weeks or about 80k LOC per month. While LOC isn’t exactly a great metric, please stick with me a moment while I break it down. In the past 3 years, during similar 10-week heavy code sprints I would achieve 35k-45k loc per 4-week period. I’ve slightly more than doubled the LOC I produce per month, but does it mean I am more productive?
It depends on what that additional 100k+ LOC is. So, let’s break it down. Many would frame it as AI-Bloat, but It isn’t; its defensive infrastructure, consistent standards, and better code comments I tend to negotiate myself out of doing in the name of velocity.
Let’s dive into the details of what changed for me:
These tools help break through research barriers for something I’ve never built before. For example, I’ve no real frondend experience but I do have a working understanding of React and Javascript and that was enough for Claude Code to enable me to build multiple, complex React.js UX apps.
They reinforce coding best practices, which leads to more lines of code being authored. Javascript is not natively typed so when I work with node/typescript, I like to declare functions with a strongly typed object parameter and response object. I’ve had enough instances of engineers transposing two parameters and this simple best practice cuts off these difficult to uncover defects. However, that’s two new type declarations per function adding 6-20 LOC on top of the function declaration. I’m only human, I didn’t always follow my own best practice, the Coding Agent always does. The AI pays the boilerplate tax for me.
The third area that resulted in a lot of new LOC was testing (unit and integration). I’ve paid the refactor price too many times, so I tend author the least number of most impactful tests. The coding agent almost always authors additional tests I would have deemed not high enough value and skipped. Time will tell if maintaining these extra assertions becomes a tax, but for now, the additional coverage is a positive.
The Verdict:
Am I shipping features faster? No.
Am I able to ship a greater variety of features? Definitely.
Is the code quality, consistency, and documentation better? Definitely.
Coding was seldom the bottleneck for shipping features in my experience. It’s usually the entire product lifecycle and SLDC around the coding that bottlenecks feature release. I can do a greater variety of work, step into new languages faster, and the output is higher quality but the same gates that limited feature release are still there.
As for the original question, does it improve productivity? I historically measured productivity as a unit of velocity: backlog churn, story points burned, features squeezed into a release.
By that metric, AI hasn't made me more productive at all. But my definition of productivity is evolving. I’m not spending my newfound time shipping more features; I’m spending it designing better, documenting thoroughly, hardening against defects, and enforcing standards I used to be too overworked to maintain. AI didn't increase my speed, it pre-paid my technical debt. And by my standards, that is a massive productivity win realized over the life of a code base.
No. 3
July 14, 2026
The MCP Trap
This topic may ruffle some feathers so buckle up! For a while now, the hype cycle has been focused on Model Context Protocols (MCPs). The narrative is: “Expose your entire infrastructure as an MCP server and let the agent figure out what tools to call!”.
In concept, it sounds like a great idea, a secure method for allowing AI agents to connect to existing tools transforming them from chatbots to dynamic agents capable of real-time reasoning and action. However, they frequently have two major risks:
Token Tax: At a certain point, MCPs become context heavy discovery zones that require an LLM to burn through tokens figuring out what it can do before deciding what it should do. Token burn is no longer a tomorrow problem; it is actively becoming a hard operational liability as the industry strips away inference subsidies and forces engineering teams to justify their unit economics.
Security Surface: The real hidden tax of MCPs is that often they violate the principle of least privilege which requires dedicated attention to adequately creating the appropriate access controls.
I should offer a quick peace offering to the crowd: I actually really like the concept of MCPs and fully intended to use them when I started out. When implemented responsibly behind strict gateways, they are magic. But because too many of the implementations I see right now are the architectural equivalent of handing a toddler a lit Roman candle, I’ve opted for a different route: the Agent-SDK.
An Agent-SDK forms a strict contract for the Agent to operate within, limiting token discovery cost while utilizing existing privilege controls built into the API middleware. For 3rd party solutions, most already offer an SDK but when they didn’t, all the documentation was available to quickly analyze the exposed API routes and distill them into an SDK for the agent to work with. It’s a small tax to pay for security gains, control, and reliability.
This philosophy of bounded context then bled into the larger project structure. Ask anyone that has worked with me, I tend to have pretty strong feelings about folder structure, import/export rules, and general project architecture. Turns out AI agents have similar preferences and building strong structural boundaries like the Agent-SDK for the entire project works really well.
Why this works? Each of these context bounded project folders has a “coding conventions” file attached to it and clear guidance within the CLAUDE.md on when to use which. The AI agents respond incredibly well to verbose barrel exports coupled with predictable subfolder patterns in navigating project structure, reducing duplicative authoring, and preventing spaghetti code creep. When the prompt says “Do {x} in {package y}”, the CLAUDE.md file directs it to read “coding conventions for { package y}” giving the agent a very tightly defined area to work with strong guidelines how on to perform the action with minimal prompt authoring.
But what happens when you scale this from one solo operator to an engineering team of six, all running different local assistants, different custom instructions, and different prompt habits? That is where AI velocity usually fractures into chaos.
Next Tuesday, I am going to dive into The Workflow: how the shared CLAUDE.md, folder structure, and conventions files combine together to make an entire engineering department code as a unified, deterministic hivemind.
No. 4
July 21, 2026
The new Tower of Babel: LLM-enabled Engineering Teams
Imagine if you will, you hire 5 brilliant engineers and give them all Claude Code or Cursor. Output triples for the first three weeks. Everyone is high-fiving. Then, week four hits, and [main] branch becomes completely unmergeable. Why? Because AI assistants are fundamentally people-pleasers. If Dev A asks an agent to "fix this state issue," the agent will silently rewrite an entire underlying context provider without realizing Dev B is relying on that exact provider for a separate feature or worse author a duplicate near identical version.
This situation unfortunately isn’t imaginary, we’ve all read the stories, “AI enabled me / my team to build a product in 8 weeks, we are generating revenue, but now the code is unmaintainable”. LLMs have become the new Tower of Babel causing engineers to author code as if they were speaking entirely different languages from one another. It leads to spaghetti code, inconsistent standards, unnecessary package imports, duplicate functions solving the same problem. Strong, cohesive teams have figured out how to mitigate this, but most teams have not; even worse, many startup teams are just getting to know each other by the time the issue materializes.
In an AI-native engineering department, your repository governance cannot live in a static Google Doc, Github README, or a Wiki nobody looks at. It must be executable runtime infrastructure. In the last entry, I described a strong preference for project structure coupled with “best practice” convention files associated with each project folder, with explicit directives in the CLAUDE.MD file on when to use them. It’s important that we split the convention files into “Just-in-time” consumables so they don’t overwhelm the agent’s context window which could end up causing more harm than good.
How does this prevent the Babel situation? The engineer’s prompt request becomes shorter and to the point: “Add a new route to the @api package that is accessible by human and agent called update-invoice-status which allows the invoker to change the status of an invoice.” The agent then quietly reads the Api-conventions file per its standing instructions, reads the route export barrel (likely 2 in this case: one for humans and one for agents) to find where it should create the new routes, then begins its work following the coding standards set forth by the api-conventions file. All code is authored with same reasoning, tradeoffs, and best practices regardless of who is working on the task.
It’s a bit sad because one of the fascinating things about software engineering is that every engineer has their own unique style like an artist and sometimes you can even figure out the influences on their style if you work together long enough. But the goal isn’t art, it’s creating high quality, maintainable code and unfortunately the casualty is individual expression.
Successfully implementing a hive-mind AI-native engineering team doesn’t guarantee success, it shifts the bottlenecks and challenges downstream to code review. Code is now being shipped faster, often more LOC per PR than if a human had authored it, and since humans relied on AI to author it, it’s potentially not as well understood. Within my teams, we run an AST drift check against every PR, have strong linting rules to prevent agents from deviating from standards or accessing code they weren’t supposed to change within the scope of the PR, and perform an agentic code review before a two-person code review takes place. It may seem like overkill but code review is in my opinion the last bastion of quality defense in an AI-native engineering team.
Now that you’ve locked down your folder boundaries and turned your coding conventions into executable agent instructions, something magical happens: that team of five we hired earlier starts moving with the coordinated, surgical precision of a twenty-person enterprise unit. A single person isn’t a force multiplier; the entire team now is.
But this sudden hyper-efficiency triggers a dangerous existential trap for recently funded Seed and Series A startups. When your lean team is suddenly outputting code at enterprise velocity, how do you manage your unit economics?
If you are managing your runway using traditional SaaS seat licenses, unmonitored consumption tiers, or outdated estimation models, you are actively burning cash to store technical debt. Next Tuesday, we are going to look at The Economics: why traditional team structure and project estimation are dead, and how early-stage teams must adapt their burn rate to survive the AI-native landscape.
No. 5
July 28, 2026
The AI-Native Startup: Disrupting Outdated Software Economics
There is a lot of talk about who will be displaced by AI in the marketplace: engineers, designers, administrative positions, lawyers, and every other job under the sun. Though suspiciously, now that the IPO of Anthropic and OpenAI are on the horizon the doomer language about job disruption is getting walked back significantly.
My thoughts: traditional IT outsourcing is going to be in for a painful few years as “AI-Native” agencies enter the marketplace. To quote Bane from The Dark Knight Rises: “Oh, you think darkness is your ally. But you merely adopted the dark; I was born in it, molded by it.” A bit overdramatic but the point stands: restructuring an existing 100+ person shop with a goal of “becoming AI-native” will be far more difficult than starting with a handful of engineers with a fundamental philosophy of “being AI-native”.
In a traditional IT services business, efficiency is actively punished. If a traditional engineering firm quotes a startup $50,000 and 12 weeks to build a core platform integration, that cost is anchored to human hours. If an AI-native engineering agency uses human-in-the-loop agentic pipeline to ship that exact same, hardened integration in 3 weeks, legacy hourly billing forces them to slash their own revenue by 75%.
Conversely, if they bill the full $50k fixed-bid without transparency, the client eventually feels cheated when they realize AI did the heavy lifting. The incentive structures are fundamentally broken.
AI Agents are breaking this model. The senior engineer acting as the human-in-the-loop may be orchestrating a dozen agents in the completion of that fixed-bid contract. The discussion fundamentally shifts: what is the value of having a feature delivered faster, built to higher standards, and helps preserve a startup’s precious burn-rate by enabling a leaner engineering team?
This leads to a new method of quoting outsourced IT project builds: Feature Points.
The Mechanism: Instead of quoting a client "100 hours," you scope a product into deterministic Feature Points based on the underlying architecture (e.g., authoring an API route handler = 2 points; wiring a complex UI component to an SDK = 5 points).
The Alignment: The startup pays purely for backlog churn. If the agentic team delivers 50 Feature Points in week one, the startup captures immediate enterprise-grade velocity, and the engineering partner captures a fair margin for their architectural leverage. Both sides win.
I’m sure someone will come up with a cleverer name for it at some point.
VCs are getting smart to the cost efficiencies and velocity that startups should be capturing with agentic code assistants. When 2 different founders present their pitch deck to a potential investor, how does the conversation go when startup A requests 5 engineers and 9 months to reach MVP and startup B requests two engineers, $150k in Feature Points with an AI-native agency, and 4 months to reach MVP?
AI has made the idea marketplace more competitive. I believe the winners will be those who can demonstrate deep knowledge of domain, build strong customer relationships, and ruthlessly manage tech budgets through strong AI adoption. The leaner team that can focus more time in-market, dedicate more resources towards client acquisition, and maintain a flexible on-demand tech team managed by a small, highly effective in-house team is the better bet.
Which brings us to the ultimate gatekeepers of the startup ecosystem: The Venture Capitalists.
If an AI-native agency can guarantee Series-A delivery velocity for a fraction of the historical cash burn, why are early-stage VCs still underwriting $2.5M Seed rounds strictly to fund 18 months of speculative engineering headcount? Next Tuesday, I will be stepping onto the other side of the checkbook to look at The Investor’s Playbook: how the smartest VCs are fundamentally changing their due diligence and why redefining the R&D-to-GTM spend ratio is about to become the most important metric on a cap table.