The Architect

Glory Days

Software development wasn't my first field of study. In high school and college I started down the path of architectural design. I loved building out floorplans and houses in AutoCAD and SketchUp. Heck, I even built houses in Roller Coaster Tycoon 3 when they introduced walls and roofs for the rides.

I was on the FIRST robotics team at my high school, but I didn't really know where my place was. I thought the programming side could be fun, but I took a look at the code and went cross-eyed. It didn't make any sense, and I couldn't visualize how it would translate to the robot. Back then, it was either C or C++. Instead I got stuck working on the more simple tasks and busy work.

My dad is a software developer. Part of NOT wanting to do that was because I wanted to be something different. I liked computers, knowing how they work, making simple HTML websites, but I never thought I would do it as a career. That changed two years into architecture courses in college. The teacher at the time really wanted us to think more creatively and abstractly about our designs. It became more of an art class, with crazy complicated assignments. But I don't consider myself an artist. My designs tend to be pragmatic. The simple part of designing imaginary residential houses was gone. I switched majors and went into computer science.

Turns out I enjoyed it and it was something I was good at. Fifteen years later, I'm still writing software.

Or at least, I was writing software.

I'd used early autocomplete tools like Copilot, and I'd kept up with AI/LLMs as the tooling got better. But everything changed when I started using Claude in October 2025. That's when it stopped being "take code snippets from a chat bot" and became "oh, this thing will actually write code for me."

Working on a Dream

In October 2025 I "vibe coded" a few projects, mostly around atproto, just to see what the hype was. Early Opus 4 and Sonnet 4.5 were pretty good, but not great. They frequently rewrote the same function, had the memory of a potato, and I often needed to send them back to refactor things.

What I learned from that experiment is that I can go from an idea to a prototype in an afternoon. atcr.io started out as a vibe project. "What if I took distribution, but on atproto?". but it's evolved past a vibe the more complex its gotten. Theres a lot more things to consider when building a project that I don't thnk AI has caught onto yet.

What AI lets me do is break past the phase of not knowing where to begin. I knew I wanted Go. I knew I wanted atproto, distribution, and S3. But doing all of that manually would have been more effort than the experiment was worth. Now I can focus on the higher-level research and design. I can choose what technologies I want to use without having to think about every individual function that makes them up. I have a backlog of projects and ideas I've wanted to build for years, and things that would have taken a week now take a few hours.

Claude has also improved enough that I don't worry about its code output the way I used to. I still review it. But the failure mode shifted from "will this work at all" to "is this the architecture I want," and that's a different job.

There's also a freedom in being able to quickly send Claude a prompt, and step away to be with my family.

Jack of All Trades

Like most companies these days, executives are trying to find any way to fit AI into something, or get us to use more of it.

I tend to be the person everyone goes to with questions about how X or Y works. My personality also tends to send me researching when I don't know the answer, which can lead to a lot of mental exhaustion when you're everyone's encyclopedia. I've noticed people ask me fewer questions now. Bailey wrote that he misses the human connection, and I agree, to an extent, but I don't miss half my day being spent answering questions someone could have searched for themselves. What I'm glad to be rid of is the volume of low-quality interruptions.

It cuts both ways, though. People are now having AI do the investigation and the research, and when the dev or the model doesn't have enough context, the output is bad. And then the burden shifts back to me to explain why their AI was wrong.

AI has also just consumed some people. They let it write the code, co-sign the commits, create the PR, and then have another AI review the PR. They spend their days building skills and configuring MCPs and tweaking agent setups instead of doing real work. They create party-trick skills for AI, things they use one time to show off. I worry these people are deskilling themselves, and I don't think they realize it.

I think that the people most at risk of this were already on that path. Frameworks abstracted away the need to understand the browser. Stack Overflow copy-paste replaced reading the docs. Claude is just the next evolution of this. I can't stop other people from deskilling themselves, I can only control how I use it.

There have been studies that claim developers only spend 20-40% of their day writing code. The rest is spent in design, review, meetings, debugging, explaining things to stakeholders. If we outsource every aspect of the job, we lose much more than the part where our fingers were on the keyboard.

There's also a struggle on both sides of the hiring table. Everyone is using AI to write polished resumes, and nobody stands out anymore. And every company seems to think that handing Claude to a bunch of senior engineers will quadruple their output, so why hire anyone else? I can manage six Junior-Dev Claudes for less than the cost of one junior dev.

I primarily focus on devops at work. A job title vague enough that everyone does it differently. But what I've realized over the years is that what matters isn't how you implement the work, it's how you think about it. I get asked questions like "what should I learn to go into devops?" and the honest answer is: it depends. Does the job use Terraform? Pulumi? AWS? GCP? Kubernetes? GitHub Actions? CodeBuild? The question was never "what should I study." Every job does it differently. The real question is "how do I adapt" or "how do I make what I've been given faster and easier." It was never about the language, the SDK, or the platform. It was about the process. Sure there are fundamental skills and patterns you should know, but there isn't a silver bullet. And besides, who is writing terraform configs from scratch in 2026?

We'll probably see some of these lower-skill aspects phased out, the way frameworks and abstractions phased out the need to deeply understand the underlying machine. But for now, the part I enjoy is still there. I haven't outsourced my knowledge. Or my ideas. Or my experiences.

I guess I never left being an architect, its just a different medium.

P.S. I never said anything about being good at writing, so this post went through some revisions with Claude.