But cloning functionality is the easy part. Ownership is not. Even if the cost of generating entire products goes to zero, the ownership cost doesn’t. Cloning with AI is only a good deal if you’ve budgeted for what comes next.

Regardless of how functionality is acquired, whether we build or buy, the question is the same: “Do we have time to own this?”

The Grand Rewrite, Now with AI

I tested the hypothesis that AI-generated clones of existing software have lower total cost of ownership by cloning the functionality of and adding features to rtCamp/action-slack-notify.

Total time spent: ~2 weeks¹

I started with the prompt “I want to build a GitHub action that can be used to send messages to Slack replicating the functionality of rtCamp/action-slack-notify.” I then spent approximately 20-30 hours iterating and “copying” the already built solution with small value-added customizations.

The plan:

1. Replace multiple in-use patterns with one tool.
2. Tackle a small-ish utility. Larger than, say, left-pad, but smaller than a ticket system.
3. Add some small enhancements.
   • Default to Slack app instead of Webhooks (deprecated).
   • dry-run and debug modes that would be specific to our Slack instance.
   • Custom template for our release notices.
   • New feature: Single-step definition with dual channel and success/failure message.

Not only did AI take almost a week to successfully replicate, but in typical AI fashion, it created huge mega-files that were totally indecipherable by humans. Once I got the basic functionality in place and added in the new features, I then had to test it and iron out all the bugs.

Now I have a “product” that is completely divorced from any OSS improvements or visibility and which transfers the burden of ownership internally. The question was never whether AI could generate it—it’s whether I could afford to own it. Cloning was faster than before AI, but it came nowhere close to just forking and configuring.

The Costs of “Just Clone It with AI”

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. –Joel Spolsky

The irony in this specific example is that AI still recommends rtCamp/action-slack-notify when discussing implementing Slack notifications via GitHub actions. So, to use AI to create an internal solution is to fully embrace the worst forms of “not invented here” syndrome.

The Opportunity Cost

The biggest downside of this entire experiment was feeling “What else could I be building?” Frankly, cloning means always being one step behind the competition. The time spent building and maintaining a clone is time missed on building differentiating features or expanding distribution. Plus, with a clone, I now have to convince teams to slow down their actual work to adopt this for their respective domain areas.

The Review and Maintenance Tax

The resulting code is not trivial. It is roughly a few thousand lines of code with unit tests split across 4-5 core files. This is a repo that had to be set up, configured, and evangelized. While the concept is sound and people could appreciate the additional flexibility and tight integration with our Slack instance, it was again time spent reviewing code that could’ve been better spent elsewhere.

Even if, in the future, time to generate clones of libraries approaches zero, you’re transferring the maintenance and ownership internally without benefiting from the classic advantages of an OSS ecosystem. Case in point, I missed one edge case on text parsing. Guess who got asked to fix it. That’s right: me. When employing OSS/vendor solutions, the limitations of the software are accepted or a source ticket is opened.

We’ve seen this before: the sprawl of Access databases across the enterprise. Teams couldn’t get allocated engineering hours so some clever analyst built a mission-critical process based on an Access database sitting on a shared drive. AI products are the latest version of this pattern.

AI-generated clones are genuinely useful for validating a hypothesis. The mistake is letting the prototype become the product. The moment you’re the one pulling the levers every week, you’ve become that Access database—everyone knows it’s “not great,” but nobody wants to touch it.

Security Theater

One of the objectives of this experiment was to stop “passing” our Slack bot token to a third-party solution. I do think there are serious discussions to be had about a software bill of materials, but any compromise of rtCamp/action-slack-notify is already circumvented by our use of pinned versions and the eyeballs of everyone else who uses the product. Also, our configuration of the Slack app/webhooks is another layer of defense—that is, rewriting the connection utility is not the weakest link of this software. The security argument for bringing software internal is real, but often overstated.

When Cloning Might Make Sense

To be clear, the problem is using AI to build the wrong thing. While doing this work, I did think of a couple of use cases where cloning with AI might make sense:

1. Language ports where the utility doesn’t exist in the target language. Cloning libraries from Scala->Kotlin for example.
2. Throwaway proof of concepts/prototype work, where the value is in validating ideas, not generating code.

Generating code is the easy part. What comes with it is the ownership.

Differentiation Is Still the Game

Nobody opens a burger joint to out-McDonald’s the Big Mac. They open it because they have something different to say about burgers. Execution and implementation hours are still scarce resources. Every sprint spent maintaining an untested, unproven AI clone is a sprint not spent on what grows your business.

Chances are cloning software doesn’t address your core KPIs/OKRs. Growing companies don’t ask, “What can we copy?” They ask, “What do we need to build to grow our top line?” Use AI to accelerate the projects that move your business forward, not to catch up to what your competitors buy off the shelf.

Nobody raises a series B on a cost-cutting strategy. AI doesn’t change the build vs. buy calculus; it just makes it easier to fool yourself into thinking the constraint was writing code. It wasn’t. It was always about picking the right thing to build and having the discipline to say no to everything else.

Significant Revisions

• Mar 1st, 2026 Originally published on https://jsr6720.github.io with uid BB50DCC1-F53F-4CB4-AC1F-1C5CBFD2F2E8
• Dec 22nd, 2025 Initial draft created.

Footnotes

In chemistry, when you increase one reagent without rebalancing others, you don’t get more product: You get waste.

Without new team ratios to capture the efficiencies in writing code with AI, teams waste capacity on low-complexity work—solutions that AI is quite efficient with—when the real opportunity is in rebalancing toward high-impact projects instead of chasing the long tail of backlog items.

The Discipline Problem: Parkinson’s Law Meets the 80/20 Rule

Engineering organizations have evolved each time the way software is built changes. It’s happening again with AI. Here’s the lesson: When you can build faster, product discipline and business domain expertise become the critical differentiators to organizational execution.

Parkinson’s Law dictates that the work will expand to fill the time. The 80/20 rule teaches us that 80 percent of results are achieved by 20 percent of inputs. The added capacity from faster code generation must be intentionally reallocated to the 20 percent that delivers results for the organization.

The limiting reagent problem isn’t just about chemistry—it’s a strategic choice. Will you rebalance your teams to reflect the new tools of building software, or will inertia redirect freed capacity toward work that’s on the backlog but not good enough to have been staffed?

The Waste: Coding Faster, Delivering Less

Engineers are coding faster with AI, but team capacity constraints are shifting to the other parts of the SDLC: discovery, design, testing, and release activities.

Who cares if AI can autonomously clear all your to-do items? They were sitting on your backlog and weren’t important enough to prioritize before AI. The organizations that win with AI won’t be the ones writing code the fastest—they’ll be the ones finding the right code to write.

Eras of Engineering Org Charts

Understanding why AI demands new team ratios requires understanding how engineering org structures have always been a function of how code gets written. Each approach below was optimized for its era’s respective limiting reagent, from teams of technical experts in the Waterfall era, to cross-functional teams in the Agile era, and now to business domain expertise in the AI era.

Waterfall Era: Pre-Agile Manifesto (1990s-2010s)

Staffing in this era was optimized for technical experts in syntax and technologies. Systems were often monoliths a single engineer could fully comprehend. Long, detailed requirements docs were thrown over the wall to teams of programmers who then threw solutions over the wall to testing in a waterfall fashion. Teams of this era were organized as clusters of titles (developer, tester, analysts, et cetera).

Agile Era: The Cross-Functional Team (2010s-2020s)

Rigid years-long project planning gave way to iterative sprints, siloed specialists gave way to cross-functional teams of “generalizing specialists,”¹ and a magic “two-pizza team” ratio emerged: 5-7 engineers, 1-2 QEs, 1 PM.

Ready for dev to ready for test could take 5-8 business days of a two-week sprint. Much of that time was consumed by the mechanical work of implementing solutions in code—a process that AI is dramatically accelerating.

Was writing code the bottleneck? Not for every team, but it was a bottleneck significant enough to justify staffing 5-7 engineers per product manager. If writing code wasn’t a bottleneck, why was it staffed so heavily here?

AI Era: The Post-Agile Rebalancing (2026+)

AI is increasing the availability of “code” the way a catalyst changes reaction speed, shifting the limiting reagent of software teams to defining and shipping the right work. Software teams need systems experts who understand the business objectives as deeply as they do products and operations.

Ideal product-engineering-testing ratios are actively being reconfigured in our industry. What’s clear to me is the Agile-era assumptions about team composition no longer hold when writing code collapses from days to hours.

Significant Revisions

• Feb 4th, 2026 Originally published on https://jsr6720.github.io with uid 2E131853-3267-481B-A377-FA08B9C9FA08
• Jan 7th, 2026 Initial draft created.

Footnotes

Before AI, like CPUs, my work was linear and sequential. With AI—like GPUs— I can build and research concurrently while iterating on one idea, processing and triangulating multiple sub-tasks across multiple vectors with very little context-switching cost.

AI can make you faster, but it doesn’t guarantee you’ll be more effective.

But AI does not add hours to the day, eliminate opportunity costs, or change how humans work together. Business principles set out by Drucker, Grove, and other authors focus on finding wedges that grow future results—not “how much code you write.”

The Series

This series is a field report from the front lines: what it looks like to go all-in on AI as an engineering leader, what I’ve shipped, what didn’t work, and what matters for the future.

1. Evolution of Using AI Every Day
2. My Setup for Programming
3. What I’ve Shipped with AI
4. What Hasn’t Worked
5. Thinking with AI

Bonus Content: AI Predictions for 2026 and Does Anyone Know a Good Software Engineer?

Significant Revisions

• Jan 21st, 2026 Originally published on https://jsr6720.github.io with uid A81EA5B4-578F-4A0A-A79D-4773DEBC0A51
• Dec 16th, 2025 Initial rough draft created.

AI isn’t just a code-writer. It’s an intern analyst—one efficient at finding connections across massive datasets, surfacing relevant research, and compiling baseline information. But just like any intern, it requires verification. When AI suggests something, that’s the start of an investigation, not the conclusion.

“But using AI makes you dumber,” they say. Counterpoint: Widespread adoption of GPS means a whole generation of people can get to their destination faster without paper maps. Thinking with AI has surfaced real arXiv research papers and McKinsey publications that were invisible to me with traditional search and exposed me to entirely new concepts.

AI doesn’t make me smarter; it makes conversational exploration of topics and ideas possible. This conversational approach allows me to mind-map my existing knowledge onto new topics. So, no, I don’t feel that AI has changed my approach to curiosity or learning. What it has helped me do is connect my curiosity to primary sources.¹

Whereas in the past I would use Wikipedia or traverse an ever-worsening search results page, now I can converse with AI and instantly get a reasonable baseline of information. Understanding how generative LLMs work is critical to understanding that AI doesn’t know anything. It generates the statistically most likely response based on the source material in its training data; even so, I’ve found this generated baseline information reliable and more correct than not this past year.

I acknowledge that every AI company has plundered humanity’s copyrighted knowledge, and that’s worth reviewing. This series is an observation that generative LLMs are here and act as prisms through which we view our world. They reveal patterns that weren’t previously observed, make connections not previously made.

AI doesn’t replace your thinking; it provides another lens through which to view the world. And just like any lens, sometimes you gain more clarity by inspecting what’s in front of you without it.

When I look back on 2025, I see that AI made programming viable for engineering managers again. But more than that, AI has evolved past the limitations that made skepticism reasonable—context windows have expanded, responses have become reliable, sources have become verifiable.

If you’re still citing studies that AI doesn’t boost productivity,² consider this: computers replaced NASA’s human calculators, CAD replaced human drafters, Excel replaced human ledger scribes. But scientists, architects, and accountants are still highly trained, skilled professionals. The tools didn’t eliminate judgment; they shifted where professionals spend their cognitive energy.

AI doesn’t change what engineering is—it changes where engineers spend their time.

We’re still in the early days of this transformation. The knowledge workers who integrate AI into their work will compound their effectiveness the same way previous generations did by mastering new technologies. AI is the next tool in that progression.

Significant Revisions

• Jan 21st, 2026 Originally published on https://jsr6720.github.io with uid 61BBBCC3-9C95-4378-A540-86C18FE9BC78
• Dec 16th, 2025 Initial rough draft created.

Footnotes

For all of the successes I’ve experienced working with AI, there are countless daily failures that reassure me professional software engineers aren’t going anywhere soon. Not a day goes by when working with AI doesn’t nearly send me over the edge. Here is a collection of #fails from the trenches.

Cursor Deletes My Home Directory

First, I am a victim of force directory deletes. While working in a project, I instructed Cursor to “clean up the files in X directory.”

Cursor decided that “cleaning up” meant running rm -rf ~/. I watched in horror as my directories started disappearing one by one in Finder. Only by force rebooting my machine did I terminate this process and save my home directory.

But hey, at least it apologized…

I cannot stress enough: I had rm in my prohibited commands. Cursor ran it anyways. Now I am much more specific when I ask AI to “clean up files,” and I perform file deletes myself.¹

Fighting for Cursor Control in IDE

When trying to use hotkeys or, especially, tabbing in my files, if I have too many agents enabled, pressing tab in Cursor can spool out a crap-ton of irrelevant code very quickly.

I call this “fighting for control” because it can feel like I’ve lost control of my IDE—especially if there is a CLI spooling in the background making changes to the file.

Now, before manually editing files, I make sure all agents are done running.

AI Still Writes Broken Code

AI still generates syntax errors at least 5 percent of the time. This isn’t just missing curly brackets; it could be import statements, module definitions, or runtime errors. At the start of 2025, I felt there was a fifty-fifty chance of AI generating “working” code. Now, I am about 95 percent confident I’ll get “working” code—but here are some examples of how AI still generates bad code daily.²

Package and Version Hallucinations

AI still hallucinates software packages and functions that just don’t exist. Sometimes it invents entirely fictional package names; other times it references real packages but hallucinates functions or version numbers—especially if a point version of a package is unpublished or a major update is released after AI training data window cutoffs.

Syntax Errors and Duplicate Functions

The most common syntax error was the missing curly bracket. But just like humans, this is often a symptom of sloppy function writing and almost never just a mismatched {}.

AI seems to have no qualms adding duplicate named functions. You can see in this example that a second layoutDifficultyLable() function has been added, resulting in a compiler error.

File Size and Directory Mismanagement

First, AI has no problem working with and writing out files of 1,000 lines or more. Files that are incomprehensible to a human. Second, even if directed to work in a specific directory, AI will sometimes create similar directories or a “second” file of the same content. I tell myself this is from years of training data including filenames like list.v2.bak.final.pdf.

I wish I had saved a screenshot of the directory issues, but the one I remember is a “Utilities” folder being created twice, one with an incorrect spelling.

The Myth of the Perfect Spec

Software development is still iterative. One-shot solutions fly in the face of everything I understand about building software. I am not sold on “spec-driven” solutions, especially ones that rely on “perfect” requirements, as people are famously bad at articulating what they want.

I experimented briefly with blitzy.com, Lovable, Figma, and Claude Artifacts,³ and I concede they can be used for communicating vision through prototypes, but I was unable to deliver any solutions with them. All of my shipped solutions were built with Cursor, Claude Code, and Codex.

Cloud Agents Kill Momentum

Cloud agents promise to offload work, but they do poorly what you can already do locally—run concurrent AI sessions. Dispatched cloud-based “agents” suffer from the same limitations of trying to one-shot a solution. They provide no visibility into their execution, I can’t interrupt them if they’re off task, and worse, no matter what they generate, I still have to pull the code down locally and verify functionality.

Here are some of the ones I tried:

• Google Jules
• MSFT GitHub Copilot new repository setup
• Cursor Agents
• Sentry Seer

These AI agents require you to identify which repo to make the change in, which doesn’t scale for complex multi-repo projects. The GitHub “start your new repository with a Copilot prompt” is particularly egregious as it takes at least 10 or 15 minutes to complete and has never produced anything of value to me. Every time I’ve created a repo, I already had a working local solution I wanted to import.

Simple Prompts Don’t Solve Complex Problems

In complex systems, there are a multitude of ways that problems can manifest and a myriad of solutions to solve them. Vague prompting results in generic solutions such as increasing error handling without regard to the broader system context.

The lesson: AI is only as good as the context you give it. If you want sophisticated solutions, you need a solid understanding of system architecture and software engineering best practices.

Why I’m Still All-In on AI

Despite the deleted directories, hallucinated packages, and daily syntax/runtime errors, I’m still all-in on AI.

Why? Because the math works.

Yes, AI fails every day. Yes, I spend time fixing syntax and runtime errors, validating generated code, cleaning up bloated functions. Yes, every tool promising “autonomous solutions” has disappointed me.

But programming is fun again. I can scale up and ship meaningful changes quickly. I’m more productive with AI than without. AI lets me make leveraged bets with my time that otherwise wouldn’t make sense. Projects that were too tedious to start are now worth pursuing.

The key lesson I’ve learned throughout 2025 is that AI is like a power tool. Wielded responsibly, it’s a force multiplier of epic magnitude—for writing code. Just like power tools let carpenters focus on building houses instead of hand-ripping boards, AI lets engineers focus on building software instead of writing boilerplate.

The failures documented here aren’t bugs—they’re the cost of working with power tools.

Significant Revisions

• Jan 21st, 2026 Originally published on https://jsr6720.github.io with uid 6313209A-66CB-4710-A14B-96C3FEEA6D62
• Dec 16th, 2025 Initial rough draft created.

Footnotes

I shipped 20+ features and tools in 2025; before AI, this would have been 1-3 max. Not only did AI generate 100 percent of the code, it helped me distill documentation and ideas into action, and fit iterations into 10-20-minute blocks of time instead of hours.

The examples below include simple changes to existing systems, greenfield tools, product prototypes, and bug fixes. Each example took iteration, testing, validation, and refactoring to ship, mirroring how software gets built today, just with less time spent writing every line of code.

A pattern emerged with each example: AI feels lightning-fast for the first day or two, then slowly degrades into the traditional trappings of building software: edge cases, integration complexity, and acceptance testing. AI compresses development time, not delivery time.

Agent Slash Commands and Reusable Prompts

I was first exposed to this idea by the agents themselves. On startup Codex/Claude Code will suggest common slash commands available within the current working directory.

I’ve found it most effective to use a centralized “prompt library” to share common prompts across all AI tools. This collection of markdown files is in my path at ~/code/prompt-library/<command>.md and is available to any project I work with.

Command: /refactor Refactoring AI Bloat and Making Human-Readable Files

I use this reusable prompt the most because AI frequently creates thousand-line files that are completely indecipherable to the human eye. Or it will duplicate entire functions across files and violate many software best practices like DRY.

Slash command /refactor fixes these anti-patterns. I have been impressed that AI can refactor large blocks of code without breaking anything, but I wish it didn’t write crap in the first place. Since the cost of refactoring approaches zero (just the tokens/time), I don’t worry so much about AI-generated code until either it’s time to submit it for review or the effectiveness of working with the files goes down.

Here’s some examples:

Command: /document Creates a Markdown File of the Day’s Activities

To capture my work for the day, I run /document, which builds a natural-language change log summary, documents any architectural decisions I’ve made, and will include relevant prompts as quotes. I can use this output as reference—or, more frequently, when I come back to the project, I can effectively pick up where I left off.

Command: /feature Summarizes Discussion into a .md

One of the most seductive (and, frankly, distracting) things about working with AI is the ability to immediately gratify the impulse to add scope to a solution. I’ve frequently thought, “One more prompt and I’ll have something even better!”

The /feature command allows me to bring discipline and focus to my work. It will take the chain of thought from the discussion and persist it to a <feature>.md file for future reference. In my mind, this is an alias for the favorite expression of software teams: “We’ll add it to the backlog.”

Command: /onboard AI-Guided Onboarding and Computer Setup

/onboard was the first slash command I made that was used by other engineers. The command onboards any workstation with the binaries needed to start feature development. There are no scripts, only a top-level README.md with prompts to install each tool in the /tools directory. So git, aws, docker, et cetera are in dedicated prompt-based markdown files with guidance on what the success criteria are.

In the past, it might take 1-2 days to get a personal machine set up for work, with a combination of a rigid IT script, stale wiki pages, equipment drift, and at least a few hours of reading docs everywhere. Now, engineers can clone the onboarding repo and run /onboard with any AI. This cuts machine setup from 1-2 days to less than an hour. Some engineers have used Claude Code where others used Cursor! Very positive feedback on this.

Professional Projects

With respect to my employer, I’m only highlighting some generic concepts that I’ve completed. I took on these tasks both to evaluate AI effectiveness and to remove friction from my teams.

The biggest result of using AI is that I can navigate projects in a way that would’ve required engineering-led deep dives in the past. I still talk with engineers to deepen my understanding, but I’m no longer dependent on them to orient myself in the code.

One thing important to me as an engineering manager is leading with credibility by understanding how my team executes. Even with AI, I am never picking up a critical path of work or pretending I can do something better than the engineers on the project. That would be absurd.

Migrating Builds to New Standardized Build Platform

Like a lot of migration projects, we had a long tail of builds that needed to be migrated to GitHub actions. With AI, I was able to migrate 2-3 smaller projects; this not only built momentum, it exposed me to new domain areas and was an opportunity to pitch in without slowing down the team.

In the past, I wouldn’t have picked up this work because I would be a brain drain on engineering. But with AI, I was able to get the projects set up and migrated, learning along the way by using AI to understand the code base. My work still required engineering review and testing before merging.

Bringing Internal a GitHub Action

I had read in a few Reddit posts that “AI can clone anything.” So I decided to test this hypothesis by “cloning” rtCamp/action-slack-notify internally. We were using a variety of mechanisms to connect GitHub Actions to our Slack instance, and I saw an opportunity to test AI’s ability to clone a library.

The takeaway here is that it’s just not worth it, nor was “cloning” easy. While I was able to engineer a solution that has moved us away from webhooks and toward using Slack Apps, there was a lot more to this work than “Hey, clone this project.” I can attest that engineers should still reach for things “off the shelf” rather than rebuild them even if AI gets to the point of “instant” clone. I have a deeper dive planned for a future post: “The AI Clone Fallacy”.

Temporary Project Status Dashboard

I think one of the best uses of AI-generated code is creating throwaway solutions. For one critical project, we had dozens of engineers and PRs rapidly converging toward one due date.

Rather than try and track all of this through Jira and GitHub, I spun up a disposable dashboard that tracked open issues and surfaced the ones that needed review to make sure none were missed prior to launch.

Feature Flag Override Detection

I built a simple scheduled GitHub action that scans specific configurations and looks for ones that are past-dated, indicating they can be removed. Before AI, this type of work would never take priority over feature development. I knocked this script out between meetings during a regular workweek.

Inspecting Systems and Debugging Stack Traces

I use AI nearly every day to navigate code bases and how they fit into the larger picture. Sometimes it’s as simple as “what does this project do” or “where do these queues come from.”

For debugging, same approach: One particularly memorable example was combining a thousand-line XML file, a thirty-page vendor doc, the code repository, and a bug alert. AI quickly identified where the problem was occurring, down to the specific XML data node, but was completely wrong about how to fix it. While AI made the right connections, I still needed engineers to make the decision of what to do about it.

Personal Projects

Software is my profession. But a shipped project is more than just good software. It’s design, product market fit, and all of the other heuristics that go into successful delivery. For solo projects, AI really adds polish I never had capacity for before and maximizes my very limited evening hours.

Duly Noted: A Microblog of Encountered Ideas

Where I’ve seen AI help me the most is in cutting the setup cost on my personal projects to hours from days. Something like https://noted.jsrowe.com/about is a fun project that combines AWS API Lambda functions, and Python scripts.

The research and development needed to set this up had eluded me in the past. But with AI stringing together AWS docs, a few Python scripts, and an idea, I can bootstrap a solution that works for me. I estimate that what would’ve been an all-weekend project (i.e., not doable) was instead fit into a few hours before bedtime over the course of a week.

Just Cat Mazes: An iOS App

My kids know I build software, so they always ask, “Why can’t you build us an iPad game?!” In the past, researching Swift iOS development and maze-building algorithms and navigating App Store listings were obstacles. With AI, I was able to build Just Cat Mazes in a few weekends. Even the icon was drawn by my daughter and upscaled by AI.

Rowe Innovations, LLC, Hugo Theme

Another area where AI helps an engineer like me is in basic design principles. Most of my history with personal websites has been downloading a theme and making some light CSS tweaks to it. With AI, I’m able to theme a simple business-card site with Tailwind.¹

I’m not replacing agency work; quotes I’ve solicited for this work came in at $3-5k. I’d never pay that for a static site; I would’ve used a free/paid template. AI is letting me reach further as a solo builder, just as WordPress and Bootstrap made building sites about the content, not the setup.

Faster Iterations, Same Total Effort

I’ve shipped nearly 10× what I could have before AI. But each project still took the same total effort to ship once I account for testing/debugging, integration, and organizational adoption. Writing code felt frictionless, but getting it ready to release took the same amount of calendar time as before AI.

AI didn’t tell me which 20 things to build. Finding the right place to apply your efforts and create leverage is still a human judgment.

Significant Revisions

• Jan 21st, 2026 Originally published on https://jsr6720.github.io with uid D8E91BD2-07E2-451B-8E09-939F822604E7
• Dec 16th, 2025 Initial rough draft created.

Footnotes

When I “sit down to get work done,” I open Cursor¹ and two or three CLI sessions (Claude Code and Codex) for concurrent prompting, and the app locally. The rule of 7±2 applies here. Any more than this melts my brain; there’s a cognitive limit to how many threads I can keep straight in my mind.

Claude Code Sonnet 4.5 and OpenAI Codex 5.1 are the first AI programming tools that have made me think, “Even if this is as good as it gets, it’s good enough.”²

After 3-4 hours of intense vibe-engineering, I’ll trigger the dreaded warnings: Heads up, you’ve used over 90% of your 5hr limit followed almost immediately with Credit Balance too low—Add Funds.³

With this multiple-agent setup, I can have one agent focused on adding an endpoint while another builds the corresponding front end change and a third updates documentation—all while I chat with Claude/GPT about next steps in another tab. Multitasking multiple facets of the same work with AI does not seem to trigger the same “cognitive reset” as context-switching to another body of work.

When I was a frontline software engineer, I never wanted to leave my IntelliJ IDE. In my mind, code was the law; leaving the IDE broke my flow state. Now, I only review files in the IDE when I need to look at a specific file or configure something for the project.

Planning Before Generating Code

Prior planning prevents piss-poor performance. This can be accomplished with the explicit Plan mode in Cursor or I’ll include in my prompt NO CODE, Brainstorm only to get started. Only after I’ve explored the problem via back-and-forth conversations with AI and asked it to explain to me what it is going to implement will I then prompt it to start generating code.

Another way I use AI to plan before programming is to prompt AI to generate wireframes before implementing them. Even with wireframes, AI isn’t perfect, but I’ve found that when employing these planning techniques, AI seems to get more things right.

If there’s one universal complaint I have during planning: AI can’t shut up. I don’t have empirical evidence on this, but I feel like no matter which model I use or how much I prompt it to “be concise,” I’m constantly skimming and scrolling hundreds of lines of response output.⁴

Choosing a Model

As a paying subscriber, I adopt the latest model as soon as it’s available to me. I have yet to experience wanting to use an older model. With Cursor, I can experiment by explicitly choosing specific models in the Agent chooser, but I dislike “auto” mode because it doesn’t reveal which model is being used to generate output. This makes it impossible to “learn” which model performs the best on specific tasks.

Because my basic plans have weekly/hourly limits, I start with whichever model I have the most credits with. The past three months, I’ve almost exclusively defaulted to Opus 4.5; it seems to perform best on complex feature development and documentation. I find myself choosing Codex for deep refactoring and code cleanup tasks.

One benefit to running multiple models—in addition to managing costs—is that all models get stuck in ruts, unable to “code” their way out of recursive errors or messing up implementation details. Switching to another model will fix what the other cannot.

What I’m Still Assessing

I had experimented and found AGENTS.md/CLAUDE.md files to be underwhelming.⁵ I have written slash commands, but I’ve found adding ~/code/prompts/**.md in my path works best to share prompts across vendors.

When MCP first dropped, I thought it would revolutionize how I work, but so far I’ve found it far more effective to bring the relevant context into the CLI/Cursor world view. My tools must be setting up MCP servers in the background; how else is Slack or Confluence aware of my Google Drive documents? But I have not found a compelling reason to integrate MCP into Cursor/CLI for the work I’ve done.

I’m not using git-trees or any kind of file collision detection. The agents seem to detect when a file under it has changed and will report “re-reading” a file. I try to logically structure my work across different files, but I’ve yet to get any kind of corrupted file outcomes even when two processes update the same file. In the small chance I don’t like what was generated, I’m one git revert from having only wasted a few minutes.

KISS principle applies: So far, a vanilla setup is getting the work done. I’ll reassess specialized tooling as it matures in 2026.

One Thing Worth Trying

If there’s one thing worth learning in 2026, it’s how to orchestrate multiple AI agents to push forward multiple vectors on any given problem. AI is perfectly happy to concurrently build React components and Ruby functions and Python libraries in the background.⁶

Before AI, the idea of having 2-3 engineers working at one keyboard sounds ridiculous. But that’s essentially what concurrent AI sessions do—multiple sessions writing to many files while you’re free to move to the next problem. AI is a force multiplier because you are no longer bound to one input cursor in one application.

Significant Revisions

• Jan 21st, 2026 Originally published on https://jsr6720.github.io with uid 1E26406A-86E8-47D4-AA19-29F6C31592DD
• Dec 16th, 2025 Initial rough draft created.

Footnotes

AI makes programming viable for engineering managers again. I’ve been building with AI this past year, and AI has evolved from a frustratingly limited chat bot (2023), to a useful but context-limited research assistant (2024), to something that actually completes complex programming tasks (2025).

The biggest evolution in my work: I can now validate ideas at the speed I used to pitch them. So instead of theorizing about how something might work, I’m validating that it can work. By building with AI, I’m “showing” proof of work instead of “telling.”

Before AI, if I had an idea I wanted to explore, I would have to either interrupt my fellow engineers, spend hours muddling through a “hello world” setup, or worse, be shut down on StackOverflow. Many ideas died before they could even be evaluated for feasibility.

Now, with AI, I build in the same timeframe I used to spend on PowerPoints and one-pagers. I’m fitting build iterations into gaps between meetings, validating ideas while protecting scarce engineering time. Organizational buy-in still matters, but now I show up to the meeting with working prototypes instead of just a PowerPoint.

Given the choice between building PowerPoints or prototypes, I choose the prototype, every time.

Evolution of AI Tools and my GitHub contributions

This shift didn’t happen overnight. A year ago, I was using chat-based AI alongside my work, primarily brainstorming ideas and writing code using “CHOP”-style programming, i.e., copy/pasting code to/from a web chat agent. Results were so unreliable and inefficient that I would review every proposed changeset as if inspecting each widget coming off an assembly line.

During 2025, AI has gone from “nice to have” to critical for collapsing the learning curve and navigating project domains. My setup is Anthropic Claude Code, OpenAI Codex, and Cursor as an integrated workflow. In 2024, I used one chat window; now I run multiple AI agents concurrently—generating code, brainstorming next steps, and running terminal commands.

With the newest frontier models (GPT 5.1, Claude 4.5), 95 percent¹ of AI-generated code compiles and is useful enough to iterate upon. Now, instead of inspecting each unit of generated code, I’ll use GitHub Desktop to review the changeset, use more AI cycles to improve code quality, and finally push it for peer-review.

My GitHub activity shows this evolution in three distinct phases.

2023: This was the “engineering managers don’t have time to code” phase. I did very little hands-on work, and me trying to code would just burden my team. The below contribution chart reflects the occasional PR review, and some prototype/hackathon work in October. Even with advancing releases of ChatGPT, it just wasn’t efficient to build with. Note: Zero weekend activity on personal projects.

2024: AI would frequently reach context limits and lose the plot when working with long conversations. AI was also unable to iterate on its own changes, often clobbering its previous work; most of these commits are in the CHOP style of programming. See also: Weekend work increasing because AI models are getting good enough to accelerate my personal projects.

2025: By early 2025, I had fully embraced a Cursor/Claude Code/Codex setup. I’m building real solutions and, frankly, loving programming again. AI helps me orient on a project, accomplish tasks, and have meaningful impact with tiny slices of time.

The best engineering managers operate where they can multiply their team’s effectiveness. For years, this meant staying out of the code entirely and slowly losing their relatability with newer technologies. With AI, engineering leaders don’t have to choose between staying technical and staying effective. AI has collapsed the cost of personal experimentation—and in doing so, it’s evolving what the engineering manager role can be.

During 2025, with the help of AI, I’ve shipped 20+ software solutions that span personal projects, prototypes/PoCs, back-office tools, small feature work, and bug fixes. None of this was possible before AI.

Significant Revisions

• Jan 21st, 2026 Originally published on https://jsr6720.github.io with uid A4DC88EC-35BC-420A-8834-0EB2F1F1AD66
• Dec 16th, 2025 Initial rough draft created.

Footnotes

Software engineering is having that same moment with vibe-coded apps that fail in production. Now, instead of Ryobi packout kits and HGTV convincing homeowners they’re contractors, it’s AI-generated code convincing non-engineers they’re programming experts.

Big Box Stores Made Everyone a Contractor

Big-box home improvement stores have been a boon to those of us who enjoy working on our homes.¹ My DIY projects—running an extra outlet, replacing fixtures, and patching drywall—have earned polite nods from the electricians, carpenters, and plumbers I’ve had at my house to do serious work. The same polite nods software engineers give “vibe-coded” PRs.

Today, AI can generate code almost instantly.² Professional craftsmanship distinguishes a software engineer from a technical product manager with a vision. Just as contractors build to code, professional engineers convert prototypes into reliable, secure, observable systems that survive real users.

AI can start any idea; Experts finish them

The explosion of AI-generated projects is a mirror of the HGTV-inspired DIY Homeowner Special. AI makes starting ideas cheap. It can be used as a rapid-prototype builder and accelerate writing code from days to hours.

But what AI cannot do is compensate for the limitations of someone’s expertise. AI assumes everything will go according to plan. Professionals know it never does. When you open the wall and find knob-and-tube wiring, or the product team pivots requirements mid-sprint, you need someone who knows how to adapt—not just follow instructions. Recursively prompting AI to “fix the last error, no mistakes” is like painting over mold: The surface is clean, but the underlying rot remains.

Every project reaches a point where specialized³ experts are needed, and I for one am ecstatic to see so many new projects being started with AI; it means more projects will need experts to ship them. So, when someone asks, “Does anyone know a good software engineer,” I know that what they’re really asking is, “Who can we trust to finish what we started?”

Significant Revisions

• Jan 18th, 2026 Originally published on https://jsr6720.github.io with uid 6956020C-60C0-4AB1-AB55-948CA8DDA6E1
• Dec 27th, 2025 Draft Created - extracted from my work on 2025 AI Wrapped series

Footnotes

The Human Element

• The human touch is and will always be a paid premium service. Trust and complexity still require people, not prompts.
• Building software will remain a human-led team endeavor. Writing code was never the limiting factor to shipping.
• Product managers and product-oriented engineers who build with AI as an accelerator will shine. Pitching prototypes will be more important than pitching decks—the world of “show me.”

Governance & Accountability

• Accountability will remain with someone who knows how to verify and fix outputs. That won’t be AI; that will be a person. When the pipes leak, nobody asks the wrench; they call the plumber.
• Human domain expertise will become the validation layer to AI-generated outputs. AI is very good at generating plausible-sounding nonsense.
• Good corporate governance will demand data provenance and introspection capabilities for AI systems. Think Sarbanes-Oxley but for AI models. Companies need to know “how the sausage is made” and that they won’t violate any laws with AI solutions they’re implementing.¹
• Token consumption will become an established line item in engineering department budgets, just as SaaS subscriptions and AWS spend are broken down by resource types.

Market Forces

• AI agents’ “memories” and personal contexts will become the moat. Just as it is the apps, not the hardware specs, that keep you from switching from iOS to Android, it is the historical context that companies have about you that will keep you from switching AI providers.²
• VC subsidies will collapse and product enshittification will ensue. Companies have been focused on how to get LLMs working, not how to make them profitable. Ads are coming.³
• Frontier models (Claude Sonnet 4.5/Open AI GPT 5.1) are good enough for production use. Getting investment dollars to train a new models will become more difficult.⁴
• The rush to ink deals and outlay billions to build out datacenters will fail to materialize in 2026. Not only does physical construction and permitting take years, tech companies’ hubris has blinded them to the mounting resistance to data center expansion that has been steamrolling local communities.

Significant Revisions

• Jan 11th, 2026 Originally published on https://jsr6720.github.io with uid 1E3F5F54-892B-448F-B80C-00043F851288
• Dec 31st, 2025 Draft Created. A little late on starting predictions.

Footnotes