My workflow is often to plan with ChatGPT and what I was getting at here is ChatGPT can often hallucinate features of 3rd party libraries. I usually dump the plan from ChatGPT straight into Claude Code and only look at the details when I'm testing.

That said, I've become more careful in auditing the plans so I don't run in to issues like this.

What’s changed isn’t that the same engineers did a 180 on principles, it’s that the discourse got hijacked by a new set of people who think shipping fast with AI is cooler than sweating over type systems. The obsession with performance purity was always more of a niche cultural flex than a universal law, and now the flex du jour is “look how much I can outsource to the machine.”

I'm using Typescript and Rust and I think it's critical to use strict typing with LLMs to catch simple bugs.

I've worked at Uber as an infra engineer and at Gem as an engineering manager so I do consider myself an "actual professional developer". The critical bit is the context of the project I'm working on. If I were at a tech company building software, I'd be much more reticent to ship AI generated PRs whole cloth.

Having to instead express all that (including the business-related part, since the agent has no context of that) in a verbose language (English) feels counter-productive, and is counter-productive in my experience.

I've successfully one-shotted easy self-contained, throwaway tasks ("make me a program that fills Redis with random keys and values" - Claude will one-shot that) but when it comes to working with complex existing codebases I've never seen the benefits - having to explain all the context to the agent and correcting its mistakes takes longer than just doing it myself (worse, it's unpredictable - I know roughly how long something will take, but it's impossible to tell in advance whether an agent will one-shot it successfully or require longer babysitting than just doing it manually from the beginning).

IME it's faster to not try to edit the same code in parallel because of the cost of merging.

The check-ins are much more frequent and the instructions much lower level than what you’d give to a team if you were running it.

Do you have an example of a large application you’ve released with this methodology that has real paying users that isn’t in the AI space?

  > very good at writing design docs

from 'product briefs' or something else?

Initially I would barely read any of the code generated and as my project has grown in size, I have approached the limits of that approach.

Often because Claude Code makes very poor architectural choices.

You articulated what I was wrestling with in the post perfectly.

The big issue is that, even though there is a logical side to it, part is adapting to a close system that can change under your feet. New model, new prompt, there goes your practice.

Absolutely. And what I find fascinating that this experience is highly personal. I read probably 876 different “How I code with LLMs” and I can honestly say not a single thing I read and tried (and I tried A LOT) “worked” for me…

I think it's undeniable that in narrow well controlled use cases the AI does give you a bump. Once you move beyond that though the time you have to spend on cleanup starts to seriously eat into any efficiency gains.

And if you're in a domain you know very little about, I think any use case beyond helping you learn a little quicker is a net negative.

It's management!

I find myself asking very similar questions to you: how much detail is too much? How likely is this to succeed without my assistance? If it does succeed, will I need to refactor? Am I wasting my time delegating or should I just do it?

It's almost identical to when I delegate a task to a junior... only the feedback cycle of "did I guess correctly here" is a lot faster... and unlike a junior, the AI will never get better from the experience.

Writing code is my favorite part of the job, why would I outsource it so I can spend even more time reading and QAing?

People who vibe code don't care about the code, but about producing something that delivers value, whatever that may be. Code is just an intermediate artifact to achieve that goal. ML tools are great for this.

People who program care about the code. They want to understand how it works, what it does, in addition to whether it achieves what they need. They may also care about its quality, efficiency, maintainability, and other criteria. ML tools can be helpful for programming, but they're not a panacea. There is no shortcut for building robust, high quality software. A human still needs to understand whatever the tool produces, and ensure that it meets their quality criteria. Maybe this will change, and future generations of this tech will produce high quality software without hand-holding, but frankly, I wouldn't bet on the current approaches to get us there.

When I write piece of code that is elegant, efficient, and -- "right" -- I get a dopamine rush, like I finished a difficult crossword puzzle. Seems like that joy is going to go away, replaced by something more akin to developing a good relatioship with a slightly quirky colleague who happens to be real good (and fast) at some things -- especially things management likes, like N LOC per week -- but this colleague sucks up to everyone, always thinks they have the right answer, often seems to understand things on a superficial level, and oh -- works for $200 / month...

Shades of outsourcing to other continents...

I don’t find the issue to be breaking other parts of the app, more-so that new features don’t work as advertised by Claude.

One of my takeaways here is that I should give Claude an integration test harness and tell it that it must finish running that successfully before committing any code.

I now think TDD can play a big part. I don’t have much of a background in unit testing. For a recent TypeScript utility mini project, I took an outside-in approach using mocks where necessary. This started as a prototyping and modelling phase, getting the design right before committing to implementation code. This was about refining the types and function signatures, and mocking the components that didn’t exist at that point. The LLM didn’t have involvement at this stage, as it was about the problem domain, the shape and flow of the data. Moving on from there, I was able to save a lot of time because SuperMaven in Cursor had enough context and understanding at that point to make very precise guesses about what I wanted, so I could tab autocomplete through a reasonable amount of boilerplate implementation code. I was also able to get away with writing a couple of happy path tests for most components, and get the agentic LLM to generate sad path tests. Most of which I kept, including one that smoked out a flaw in my design.

That’s essentially the process I’m gravitating towards. Human begins the process, models the design, sets the constraints, and then the LLM saves time in a limited and supervised way whilst being kept on a short leash.

I dunno.