Seven Weeks with Claude Code: A Skeptic's Field Notes

I've written code for over a quarter of a century. I've seen so many trends and technologies come and go. And though I try to keep an eye on the future, I'm not an early adopter. I want proof it has staying power before I commit.

Early on, as AI took its first public steps, I didn't view it as either promising or perilous. It was a whole lot of really sticky technology involving science and math and theory. It intrigued me, but I didn't see an application for it. So, I moved on to other things more applicable to my day-to-day work.

The next time I encountered AI was when the first image generators popped up, and everyone in my social networks were sharing them around. It was fun, a mere curiosity. The generators were woefully inept, and incapable of creating anything other than nightmare fuel. Nothing important to pay attention to here. I was curious, but nothing more than that.

And then LLMS started to gain popularity. It started to show up in places I visited and on apps I used. And it was not good at pretty much anything. The slop began to flow, and my curiosity curdled into skepticism.

Almost overnight, the sprinkling of slop became a torrent. Reports came out about people turning their entire life over to AI with horrifying results. Corporate execs started treating AI as an easy solution for slashing payroll and appeasing shareholders. Some of the biggest cheerleaders for AI turned out to also be cheering for fascism. Negative polarization ensued. Skepticism became resistance.

Making the Leap Now, if that's how things still stood, I wouldn't be here writing this. What changed?

For starters, I had to try to find a job. Between my last job search in 2022 and now, a lot changed. So many job postings I looked at either required AI experience, or a willingness to learn. What had been a curiosity before was now a reality of the marketplace. The pressure to adapt was building.

Then there was a skill gap that the job market made concrete. Posting after posting listed Laravel, Node, or Python as either a requirement or a strong preference. My stack history is what it is. I spent most of my career on LAMP stacks, working with whatever technology my employers needed. I don't regret that. Few of us get to choose our stack. But there's a difference between what I couldn't control then and what I can do something about now. It was essential to close that gap. The pressure kept building.

As such, I started doing coding exercises on CodeSignal. While I used my own skills to figure them out, sometimes I got stuck and needed to use its AI coding assistant. It wasn't perfect, but it almost always was helpful. It gave me a sense of AI's possibility.

Finally, I could feel the general consensus on the technology change. Especially for writing code. On social media, I followed people with a wide variety of opinions on AI. Some hated it, some loved it, most were in the middle. Through it all, the signal amongst the noise was clear: I must pay attention. To AI in general, and Claude Code specifically.

One of my goals in my job search was to build a test project using Laravel. I wanted to show my proficiency with the framework and build a portfolio of projects I could share through my GitHub account. It made sense. But I just couldn't get started. I'm no stranger to hard work. But this project's payoff was theoretical at best, and its direction was not apparent to me. It was tough to get started.

By March 2026, I had yet to start the project. At the same time, my network made it clear. With Claude Code, the smoke was now fire.

I decided to see what I could do with Claude Code. I would use it to help me build out Movie Zone, my movie logging project using Laravel. It might be a disaster. It might be a wonder machine. whatever it was, I had to find out for myself.

First Impressions As I started, I had no idea what to expect. Sure, I had the experience with CodeSignal, but that was a controlled environment, with very specific solutions already solved to work with. How would Claude Code react in an open-ended project? Would it be just complete spaghetti slop? Would it ignore long settled standards? Would it use the wrong kind of indent?

To my relief none of that happened. Most of the code it wrote looked an awful lot like the code I'd write myself. It was clean, it followed standards, and it worked. And even if it wasn't optimized the first time around, asking it to optimize the code in a second pass did the trick. Not just for simple things either. It could build out thornier business logic with very little hand holding. Ask it to write tests, and it would do it. And not just tests for testing's sake, but tests that were meaningful.

What impressed me more than the code was how well it asked questions. I expected it to write code. I did not expect it to ask the right questions. It asked when it needed clarification. It asked when it needed a decision made. And more than once, the question it asked forced me to think through something I hadn't fully worked out yet. That's not a junior developer move. That's not even a guaranteed senior developer move. A tool that asks good questions is a tool that makes you think better.

For much of the project, I had definite features in mind. But at some point, all of these were built out. Here is where I really took Claude Code out to test its mettle. I wanted to see what it might suggest for expanding the project. It came back with clear recommendations. It suggested new packages to install to get a particular feature to work. It could worry about the things that always bog down projects, and I could focus on the big picture. I could focus less on how it got built, and what to build and the why to build it.

All in all, this was a heck of a first impression.

First Frustrations No tool is perfect. And this is true for Claude Code. As great as it was, and still is, to use, after a while I ran into some friction.

The first issue I encountered was that sometimes it would write raw SQL, rather than using parameters. This wasn't an all the time thing, usually it wrote code that used Eloquent exactly as it should be used. But even one raw query that unquestionably passed a variable into the SQL could be disastrous. I knew enough to catch it and correct it. But this is exactly the kind of thing that's easy to miss if you don't already know what SQL injection is and why it matters. The tool won't warn you. That's on you.

Less threatening, but still annoying, was how it built out front end code. Compared to the backend, where it would utilize Laravel's features for encouraging OOP very well, it was more cavalier in its sloppiness with the frontend. It would default to copying and pasting code, rather than seeking out opportunities to create components. It placed JavaScript directly into template files. And rather than giving the html elements classes so that styles could be managed centrally, it would hardcode things like colors into the templates. Style changes, which with the right setup could be done in seconds, took much longer because of all of the hard-coded values that had to be changed. I don't fault Claude Code for this. I've spent most of my career as a back-end developer, I get it. But we all have room for improvement.

The most annoying problems I ran into are situations where Claude Code just is not equipped to understand what is going on. The worst example was when there was a fatal error somewhere in classes being tested. If you've worked with PHPUnit, you know that if there's a fatal error within the code being tested, it doesn't necessarily tell you that. Claude Code cannot function unless it's getting output to parse. And it isn't good at failing gracefully when it doesn't get that output. It will get stuck in a loop of futile guessing, burning up usage and wasting time. The best way I found to deal with this is to always require approval when it runs the full test suite and pay attention for it trying to run it multiple times in a row.

Less common, but just as annoying, was when there was a conflict with the preview server port it spun up. It would try to change the port, but that's not possible given how its preview tool works. This was an easy enough fix, as I added an instruction for it to ask me first if its port was correct before it got to work.

None of these problems stopped me for long. Each one had a workable solution, and none of them changed the math: the tool was delivering more than it was costing.

My Final Verdict Those issues aside, my initial experiences with Claude Code have been very positive. But I have a lot of experience with PHP and JavaScript, and I know a thing or two about how to build an application from scratch with these languages. If something is wrong, I can spot it quickly, and work with Claude Code to fix it. I never push the code to my main branch without doing a PR, and I don't merge the PR until I have looked every line of changes over myself. Thus, my confidence level of what I'm shipping is very high.

But if I were to get into a language or architecture I was not familiar with, my confidence level would not be nearly as high. Whether the output of Claude Code is right or not, it will always be confident in what it did. Thus, I cannot rely upon its opinion of the work.

That isn't to say I would not use it to help me broaden my experience with other languages. I have projects in both Python and Node I'm planning on starting. But I must be more cautious about putting live code out. I've seen enough of Claude Code's capabilities to trust that it can solve problems. But I must never trust it enough to not verify the quality of its work myself.

The throughline in all of this is expertise. Claude Code works as well as your ability to evaluate what it does. And your ability to evaluate what it does comes down to what you already know. The tool amplifies existing expertise. It doesn't substitute for it.

In a lot of ways, I compare Claude Code to an overeager and talented junior developer. It has the knowledge of how to build things and can do some great work. But it doesn't have the wisdom to know specifically what it can't and shouldn't do. I have no qualms giving it complex tasks to accomplish, to push through the thorniest of problems. But I'm not about to let its work out on production without a good once over.

What I Built Working with Claude Code In the seven weeks since I started using Claude Code, here are the projects I've worked on:

1. Movie Zone - A fully featured movie logging website built on Laravel. I put a demo version live, and also posted the code to GitHub

2. Carrel - I built a full featured writing app, also built on Laravel, that I use for all of my writing work (including this piece). A public version is currently under development.

3. Book Minder - A tool I built for my wife so she can manage the fictional universes, characters, and relationships in her novels. This one was a different kind of engineering challenge. My wife is not a developer. So, I had to gather requirements, figure out the best UX for her, and make sure I didn't over-engineer something for a user who just needs it to work. Claude Code wrote the code. I had to make sure it was actually useful.

4. Director Connections - Recognizing that the director connections feature in Movie Zone had value as a standalone tool, I made the call to port it and built it out as a WordPress plugin on my writing website. The feature was the same. The architecture was different. That decision was mine.

I did these projects even as I continued my job search and wrote a full slate of television and movie newsletters! This was possible because Claude Code took care of the bulky and repetitive steps of the development process. I was able to keep my focus on the projects at large. Instead of the "how", I could focus on the "what" and the "why".

It collapsed the amount of time I needed to create and build tools drastically. Which is both exciting and scary.

The Wrap-Up My concerns about AI persist. Not necessarily about Claude itself, but about AI in general.

I still have serious questions about the environmental impact of the rapid expansion of AI. Several of the biggest players with the technology are tripping over themselves to build new fossil fuel guzzling power plants. There's a clear problem with AI data centers causing unacceptable levels of pollution that harm the communities around them. It's a legitimate concern that needs to be addressed sooner rather than later.

The current AI rush also has a lot of the same feel as previous tech bubbles. Everyone suddenly sees AI as the "big thing" and it brings all of the speculators and people looking to get rich quick out. Some of this can't be avoided in even the best case, but there's also the risk that bedrock companies will overextend themself, and when the bubble pops (or even just gets smaller), it will all fall apart. And if that happens, the global economy could go with it.

Relatedly, the dramatic growth of AI raises serious concerns regarding the labor force. Not necessarily the tools themselves, but how those tools are sold. They are being sold by some companies as a way to either get rid of most of a company's workforce, or at least to destroy any leverage workers might have in asserting their power in the marketplace. If any of the most drastic predictions come true (unlikely, but not impossible), the white-collar workforce the world over might be destroyed. These fears must be addressed, and we all must be thinking of solutions if the worst case, or the more likely less bad but still bad cases, happen.

Finally, as powerful as tools like Claude Code are, they only work as well as the hands wielding them. I am very happy with the stability and reliability of the projects I've worked on. But that's because I have solid knowledge of the technology I'm working with. If I stepped into a domain I'm not familiar with I could make something disastrous and not even know it. We will never be rid of people who don't know what they are doing but think they are experts. AI is a force multiplier for their incompetency and bad risk-taking.

The question is no longer whether to engage with this technology. For those of us in software engineering, that ship has sailed. The question is whether engineers who know what good code looks like are going to insist on that standard, or whether we're going to let the same boosters who oversold every previous wave shape what this one becomes. What happens when someone vibe codes a new app who has never heard of SQL injection? Bad things, that's what.