xgb84j

You either die a software engineer or you live long enough to see yourself become the project manager.

Claude Code has the issue that sub agents inherit the thinking level. This means that to use a smarter or dumber sub agent you need a different model. That's not a particularly good reason, but that's my one use case for Sonnet.

It might be that you're just working on projects where LLMs don't provide much benefit.

The second thing is that using LLMs in a useful way is a skill in itself.

I do not believe you read my comment in good conscience.

>>Claude was consistently doing database operations in a for loop, where it could use batch operations.

>>The code in the end is better than a lot of the code I've seen humans write.

>It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.

There is no irony because I have seen humans do the same thing. The difference is that the human was paid 50x more.

I do not understand your arguments around outsource shops. I get clients. They want something. I deliver. There is not a lot of complexity to this. I am not a world start programmer that has 50 clients to choose from.

>>Set up excellent testing.

>Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.

I set up excellent testing the same way a CTO would set up excellent testing: I give clear guidelines on the architecture I want to see on the project. I then review key parts and samples of it and give feedback. When it looks good I mark it as done and move on. Any bugs or defects always result in additional test coverage.

I'm happy to have a constructive discussion about this, but I do not appreciate your sarcastic, tongue-in-cheek, condescending tone. It makes people not wanting to communicate with you.

In my country we have very protective labor laws, but what you describe is one of the few reasons that allow for instant termination: You refuse a direct order. If your boss says that he does not care about long term consequences and he want things done a certain way, you do it that way. Everything else is unprofessional. Your opinion on what you think he wants is legally irrelevant.

All the projects I work on have an explorative character. It's very difficult to design a product, build it and sell it. You need actual customer feedback. LLM code gives you a much faster feedback loop.

If you have a clearly defined problem with customers lined up, you should absolutely use a different approach. In the startup world you often don't and you already know that you will throw away or rework 90% of the code before the first line is even written. The best thing to do then is to have clear boundaries and good tests, which allow ripping out parts of the codebase and reworking them.

I am hand-holding the AI on the e2e setup. It mostly consists of Playwright + Cucumber + a test API to set up more complex scenarios. I also have unit tests for logic that lends itself to that. I also use mocked LLM responses for LLM projects.

If you enjoy writing tests, AI is really good at finding appropriate fixes for bugs that are easily reproducable. Just make sure to always have another AI review the fix. Otherwise you get a lot very, very dirty quickfixes. (At least in my experience.)

I am currently writing a lot of code that I am not reviewing anymore. These are all the things that make it work for me:

- Work on small projects (< 500k lines of code).

- Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.

- Have clearly defined API boundaries. Examples: If the back end is solid you can just vibe code the first version of a front end according to some mockup. Define a data pipeline with steps and clear contracts of what data gets passed around and what each step does. If the LLM messes up one step, rip it out and rewrite it.

- Have clearly set up workflows for tasks. Start with a "ask me everything" phase, then comes a plan phase, a review phase, an implementation phase, another review phase and then the integration phase. Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through.

- Set up excellent testing. Build your whole architecture around being easy to test.

- Have skills for common problems. For one of my projects I had to set up a skill on how to query the ORM, because Claude was consistently doing database operations in a for loop, where it could use batch operations.

The code in the end is better than a lot of the code I've seen humans write.

I don't think this works for everybody and every project. If you have a culture that values code quality and readability, if you work on large existing projects, if you have to nail the architecture of some non-trivial piece of software etc. you are going to have a bad time.

On the other hand you can probably build the MVP of your AI-supported CRUD app 10-20x faster.

I think a lot of the discussions around development tools and techniques just stem from two facts:

1. Developers work on widely different projects with different management and constraints.

2. Tools, libraries, frameworks and code style have to match your mental model, otherwise you going to dislike them.

Could you share what projects you are working on? (tech stack and size)

I am mostly working on small to medium sized Next.js and Kotlin projects and Claude works really well, while Codex often misunderstood my instructions, while I was testing it.

Mediocre is fine for many tasks. What makes a good software engineer is that he spots the few places in every software where mediocre is not good enough.

Hey, I just wanted to let you know that I have the _exact_ same issue as you since 2 years. It was much worse than what you described 2 years ago. Now it's just very annoying.

The diagnosis I got from my therapist is PTSD from my chikdhood due to the strong connection between stress and body.

The only thing I found that alleviates my symptoms short term is lots of Buddhist meditation (1-2 hours per day).

I wish you all the best and thank you so much for sharing.

When learning new stuff I consider 2 things: - How much fun is the actual learning? - Can I actually apply what I am learning?

So I would learn things that are either fun for you to learn or things that you can directly apply.

For AI this means you probably should learn about it if you are really interested and enjoy going through build-your-own-NN tutorials or if you have good chances of switching to a role where you can use your new skills.

Edit: Basically investing anything (also time) is risky. So invest in things that directly pay off or bring you joy regardless of the outcome.

Could you elaborate on what will happen in July?

Thank you for this in-depth reply! Your answer makes a lot of sense. Also thank you for writing the article!