This is tautological. If you keep instructions dumbed-down enough for AI to work well, it will work well.

The problem is that AI needs to be spoon-fed overly detailed dos and donts, and even then the output can't be trusted without carefully checking it. It's easy to reach a point where breaking down the problem into pieces small enough for AI to understand takes more work than just writing the code.

AI may save time when it generates the right thing on the first try, but that's a gamble. The code may need multiple rounds of fixups, or end up needing a manual rewrite anyway, after wasting time and effort on instructing the AI. The ceiling of AI capabilities is very uneven and unpredictable.

Even worse, the AI can confidently generate code that looks superficially correct, but has subtle bugs/omissions/misinterpretations that end up costing way more time and effort than the AI saved. It has uncanny ability to write nicely structured, well-commented code that is just wrong.

I made an STT tool (guess who wrote it for me) and have a bluetooth mic. I spend 10 minutes pacing and telling the AI what I need it to build, and how to build it. Then it goes off and builds it, and meanwhile I go to the next Claude Code instance on a different project, and do the same thing there. Then do the same for a third, and maybe by that time the first is ready for more direction. Depending on how good you are with context switching and quickly designing complex systems and communicating those designs, you can get a whole lot done in parallel. The problems you're describing can be solved, if you're careful and detailed.

It's a brave, weird and crazy new world. "The future is now, old man."

Young man, software often has more than 50 lines of code that merely merges basic examples from two libraries. That stuff is useful too, but that's a 0.5x intern, not a 10x developer.

I've told the same Claude to write me unit tests for a very well known well-documented API. It was too dumb to deduce what edge cases it should test, so I also had to give it a detailed list of what to test and how. Despite all of that, it still wrote crappy tests that misused the API. It couldn't properly diagnose the failures, and kept adding code for non-existing problems. It was bad at applying fixes even when told exactly what to fix. I've wasted a lot of time cleaning up crappy code and diagnosing AI-made mistakes. It would have been quicker to write it all myself.

I've tried Claude and GPT4o for a task that required translating imperative code that writes structured data to disk field by field into explicit schema definitions. It was an easy, but tedious task (I've had many structs to convert). AI hallucinated a bunch of fields, and got many types wrong, wasting a lot of my time on diagnosing serialization issues. I really wanted it to work, but I've burned over $100 in API credits (not counting subscriptions) trying various editors and approaches. I've wasted time and money managing context for it, to give it enough of the codebase to stop it from hallucinating the missing parts, but also carefully trim it to avoid distracting it or causing rot. It just couldn't do the work precisely. In the end I had scrap it all, and do it by hand myself.

I've tried gpt4o and 4-mini-high to write me a specific image processing operation. They could discuss the problem with seemingly great understanding (referencing academic research, advanced data structures). I even got a Python that had correct syntax on the first try! But the implementation had a fundamental flaw that caused numeric overflows. AI couldn't fix it itself (kept inventing stupid workarounds that didn't work or even defeated the point of the whole algorithm). When told step by step what to do to fix it, it kept breaking other things in the process.

I've tried to make AI upgrade code using an older version of a dependency to a newer one. I've provided it with relevant quotes from the docs (I know it would have been newer than its knowledge cutoff), and even converted parts of the code myself, so it could just follow the pattern. The AI couldn't properly copy-paste code from one function to another. It kept reverting things. When I pointed out the issues, it kept apologising, saying what new APIs it's going to use, and then use the old APIs again!

I've also briefly tried GH copilot, but it acted like level 1 tech support, despite burning tokens of a more capable model.

But the hard part is figuring out the more complex parts. Getting that right is what takes the time, not typing in the more trivial parts.

The point is that good software engineers are good at doing the "hard part". So good that they have a backlog of "trivial" typing tasks. In a well functioning organization they would hand off the backlog of trivial parts to less experienced engineers, who might be herded by a manager. Now we don't need the less experienced engineers or the manager to herd them.

And how do we get new experienced engineers?

good != experienced. The barrier to entry is simply becoming much, much higher.

Not typing the trivial parts is pretty great though

I think most developers bypass the typing of the trivial part by just using a library or a framework. And sometimes typing trivial things can be relaxing, especially after an intense bout with a complex thing.

Being forced to type in trivial boilerplate means you're very motivated to abstract it. Not saying this'll offset anything but I can see AI making codebases much more verbose

Until it spends 10 minutes fucking up the trivial part and then youre 10 minutes down and you still have to do it yourself.

It can be, but if you're familiar with what you're working with and have experience with other systems that have transferrable knowledge, again, it can be an advantage.

I was surprised with claude code I was able to get a few complex things done that I had anticipated to be a few weeks to uncover, stitch together and get moving.

Instead I pushed Claude to consistently present the correct udnerstanding of the problem, strucutre, approach to solving things, and only after that was OK, was it allowed to propose changes.

True to it's shiny things corpus, it will over complicate things because it hasn't learned that less is more. Maybe that reflects the corpus of the average code.

Looking at how folks are setting up their claude.md and agents can go a long way if you haven't had a chance yet.

Is the implication here that you consider yourself an above-average engineer?

The implication is that I'm finding it straightforward to handle the issues that other people here seem to consider insurmountable. And they seem to be directly related to how good one is at building software.

I’ve seen claims of this flavour in the past, and it often turns out that the person making the claim is writing software that is a lot less novel / complicated than the software the other engineers (who struggle to find uses for ai) are writing.

might it not be the other way round? For all we know its mediocre devs who are relishing the prospect of doing jack shit all day and still being able to submit some auto generated PRs. Being "amazed" at what it produces when someone with higher standards might be less than amazed.

I find it impossible to work out who to trust on the subject, given that I'm not working directly with them, so remain entirely on the fence.

Sure, absolutely. But that's the hard part of software engineering. The dream is composing software from small components and adding new features by just writing more small components.

But nobody has ever managed to get there despite decades of research and work done in this area. Look at the work of Gerald Sussman (of SICP fame), for example.

So all you're saying is it makes the easy bit easier if you've already done, and continue to do, the hard bit. This is one of the points made in TFA. You might be able to go 200mph in a straight line, but you always need to slow down for the corners.

Of course there is an upper limit for AI. There's an upper limit for humans too.

What you need is just boring project management. Have a proper spec, architecture and tasks split into manageable chunks with enough information to implement them.

Then you just start watching TV and say "implement github issue #42" to Claude and it'll get on with it.

But if you say "build me facebook" and expect a shippable product, you'll have a bad time.

I agree, and the fact that in their list of scenarios that cause these not actually mentioning some people actually are 10x definitely points to them not being self-aware.

I'd be curious how skill atrophy affects engineers who use AI semi-exclusively for these trivial tasks.

I tried doing all of my work for ~1 month with copilot/claude. It didn’t cause a ton of atrophy, because it didn’t work - I couldn’t avoid actually getting involved in rewriting code

You didn't read the article