MakeThingsWork.dev

Congrats - AI Has A New Job for You

Software Engineering Is Changing

I've heard this sentiment a lot. I initially took it as people hedging their bets on whether or not AI will, in fact, replace us software engineers.

I've always been of the opinion that AI itself won't replace me, but rather that people who think AI can replace me will replace me. However, I feel like all of this speculation is drawing to a close (at least for me), and the reality isn't quite what I expected.

I read a fantastic article that described what it called a "Software Factory"1 and laid out what I believe to be the actual future of software development. I didn't just read the article and come to this conclusion, though. I was intrigued and then decided to build my own software factory to see how well it actually worked.

Let me walk you through my thoughts and then we'll do some show-and-tell.

The Hard Truths

To accept this new paradigm, I had to accept a few ideas as truths. These were not easy to come to terms with, and I would posit that they will cause the majority of pushback among software developers.

  1. AI can write good code. It's not always great, but it can churn out functional code quickly. If you've played with Claude Code or any of the other coding agents, you'll know this to be true to a certain degree. It is more than capable of delivering value, and that value is "good enough" in many cases.
  2. Hand-crafted code is losing market value. Fellow software engineers might take issue with this, but for so long you needed a "big-brain" person to write your software application. The barrier to entry was just too high for anyone without the knowledge and skills. Today, though, you usually only need a software engineer to help you write your application. Businesses and those that run them can't ignore the value of AI-generated code (or more accurately the features—the value—that the code is powering) even if it isn't perfect. The truth here is that the things we care about (the "art" of writing code) are not a necessary step for creating value.
  3. Non-coders want in, and are getting in. The shackles are off and people who have never written code in their lives are building applications. Some of them are making money. They are here to stay, and as much as we might roll our eyes at the results of what they build, I think they're here to stay. We might as well accept that and find ways to collaborate.

Congrats, AI Has A New Job for You

We will become factory builders.

As long as AI is probabilistic, you need humans to handle the deterministic side of things. The AI does not have accountability and thus it will, for the foreseeable future, fall to humans to ensure guardrails are in place. The daily task of designing and building features will be handed off to the AI while the software engineers define the boundaries. These boundaries take the form of tests, automated CI pipelines, and robust QA (preferably automated). In other words: the stuff that we don't usually enjoy doing.

But if you can build a safe environment with deterministic outputs for the AI to bounce around inside of, some interesting things can happen.

Collaboration

One of the big benefits of leveraging AI in this way, and building guardrails in this way, is the ability for non-tech people to go from ideation straight to implementation. The article I mentioned at the top talks about Stripe and how well they've integrated this idea. In theory, you could set up an AI pipeline and hook it into a Slack bot. A Product Manager could trigger a feature build right from Slack by describing the feature; the pipeline kicks off, and the end result is a reviewable PR (maybe even deployed to a sandbox) that can go through the usual review steps.

As much as I'd like to gatekeep for job security, I won't pretend I'd be okay with it from the other side of the process. If my job is to simply build the pipeline that unlocks massive amounts of value from the minds of anyone with knowledge of our products and customers, then that's not a bad role.

My First Week on the Factory Floor

badge

After coming to these conclusions, I decided to start experimenting with this and try to implement my own software factory for a personal project. I dug up my ever-present SuperTextAdventure game as 1) I'd largely stalled on it and 2) I was optimistic that this pattern would help me get it done.

I'll skip over the long-winded thought process and development and just jump to where I ended up. Just know that this is an iterative process that has room for improvement and took some effort to get to where it was workable.

The Project

Really quickly, SuperTextAdventure is something I've been working on for the past 12 years in some form or another. The idea was to have a chat window wrapped with an HP system, dice rolling capabilities, ASCII art, and an inventory so that a person could play a text adventure... but one run by another person. It's changed shape a lot over the years and that mode is still present, but I've developed a JSON format that will actually let you play a classic text adventure in the engine as well. It's built in Rails and fully adopts all Rails conventions, both backend and frontend.

I mention this to point out that I did not start from scratch. This software factory I built was able to use a lot of the work I'd done as a starting point. Doing this with a greenfield project might need a different setup.

The Assembly Line

I needed a foreman, and I chose Claude. Claude Code specifically has reached such a high level of development that I find it to be one of the more reliable agents, and the combination of skills and Claude Cloud scheduled jobs makes it an easy choice. I have no doubt you could do this with any of the other major players or build each piece yourself, but for simplicity, I chose to stay in the Anthropic ecosystem.

The Design

Here's what I decided I wanted to do:

  1. I wanted to be able to commit a file to main that described a feature in Markdown and push it to GitHub.
  2. I wanted a scheduled job to kick off every morning to check for new feature files.
  3. If found, I wanted a Claude skill to ingest the feature by creating a branch with a placeholder PR.
  4. Then I wanted a skill to plan the feature and update my original file with implementation details.
  5. Then I wanted a skill to actually build the feature, write tests, and put up a GitHub PR for me to review.

This way I could have an idea, write up a spec for it, and wake up the next morning with a PR to review!

The Skills

You can find the current skills in the supertextadventure repo2, but I'll do an overview here.

The Trigger

I set up a web scheduled task3 in the Claude web UI that runs on my repo every morning. Since all of my Claude skills are committed, when the job runs, it picks them up and can use them. My prompt for the scheduled job looks like this:

Check the specs/ directory for unprocessed spec files (files without a pr- prefix). If there are none, report "No unprocessed specs found" and exit. If there is exactly one, run /build-feature on it. If there are multiple, determine which was committed earliest using git log --diff-filter=A --format="%at %H" -- specs/<filename> for each file, and run /build-feature on the oldest one only. The remaining specs will be picked up on subsequent days.

The Guardrails

The app has pretty extensive unit and system tests to make sure everything works. These are all run in GitHub Actions and I audit them regularly when testing features. This is what I spend most of my time doing: making sure the tests work and make sense.

The Working Example - Mobile Styling

The app was never written to work on a mobile device and I thought this would be a fantastic opportunity to test my new factory.

I wrote a spec file:

# Mobile Styling

The UI was designed to fit on a larger screen and does not work well on mobile devices. Ultimately this game should be very easy to play on a phone screen. The Tailwind styling used will need to be modified so that the ENTIRE app is mobile-friendly.

This is challenging as the entire app was meant to be navigated via a text interface. This functionality needs to be maintained. For simplicity, the UI was designed with a static layout on all pages:
A header
A main content area
A text form
A sidebar
A footer

It is imperative that the functionality is preserved, but the layout does not need to remain static on mobile screens.

---

## Player-facing behavior

The player should be able to navigate the app comfortably on a mobile screen. The UI should largely consist of a content area and a place to type in text much like a messaging app. Additional UI elements can be toggled via buttons. It should be simple and intuitive and CSS/Stimulus driven.

---

## Acceptance criteria

- The entire app should be navigable on a phone screen
- All elements should be scaled to fit and look attractive on a smaller screen
  - ASCII Art
  - Forms
- The hotkey footer doesn't need to exist and can be replaced with a mobile-friendly navigation menu
- The "terminal" style feel should be persisted (imagine an old terminal computer that worked on a small phone screen)
- System tests must be written to ensure a phone screen is still functional
- Updates can include changes to overall layout
- All styles must be in the context of Tailwind CSS
- Any UI interaction needs to be done using Stimulus controllers with standard conventions

## Constraints

- The existing functionality must not change unless critically necessary
- The current styling for larger screens should remain the same unless critically necessary
- Only use Stimulus controllers for any JS code needed
- Only use Tailwind CSS (v4 standards) for any style changes - avoid writing custom CSS

That was it. I then went to sleep. When I sat down at my desk the next morning, I had a PR waiting: https://github.com/Fishy49/supertextadventure/pull/37

I pulled down the branch, fired it up, and what do you know:

super_text_mobile

Mobile styling!!!

It worked. I had a workable feature and prototype that was testable. You can look at the PR and see that there were several follow-ups from me working with Claude Code to handle things I hadn't thought of and some bugs. But it was more akin to a PR review than a full-blown feature rewrite.

What Is Lost And How We Win

AI writes code really fast. I'm sure there are those with minds powerful enough to keep up with the reviews, but I am beginning to think that the world doesn't care about naming conventions, keeping code DRY, and cyclomatic complexity. The "art" of writing code takes a backseat to the inherent benefits of getting it done quickly (even if it's not 100%).

In no way does this mean we are obsolete, but if we stand in the way and demand that things stay the way they are, then we become the bottleneck. The industry will continue to see apps and tools and games spat out the backside of LLM machinery, and our demand for a week to carefully architect a feature looks less and less appealing. So I think there's some value in shifting our focus into this new paradigm. We might be able to help keep it from flying off the rails.

Conclusions

I really feel like we're heading in this direction. Being able to build AI pipelines like this will allow the company as a whole to deliver value while the engineers work to ensure the tests and guardrails are thoroughly in place and that the pipeline is efficient and reliable.

Letting Claude bounce around these walls and generate a PR that has passing CI and a testable feature has value regardless of how it got there. I think we need to slowly start turning our minds towards thinking about building tools for collaboration and acceleration.

My implementation is a lightweight proof-of-concept for this approach that I built for my own edification; however, I was surprised at how well it worked and how much time it saved. The app is much more functional and I look forward to dropping more feature ideas into the folder and seeing what comes up.

I'm very interested in your thoughts on this and look forward to hearing from you.

You can reach me via: rick [at] makethingwork [dot] dev

I made a follow-up to this post where I talk about building my own orchestration application: Seneschal. Check it out here:

https://blog.makethingswork.dev/i-upgraded-my-ai-factory/

  1. https://alexop.dev/posts/the-software-factory/↩

  2. https://github.com/Fishy49/supertextadventure/tree/main/.claude/skills↩

  3. https://code.claude.com/docs/en/web-scheduled-tasks↩

#ai #rails