For me, it's like reading prose with "Not X, not Y, just Z": it's technically correct, but grates like fingernails on a chalkboard.

I have real trouble sometimes, reading what SOTA (Fable, etc) generate - no isolation or partitioning at all.

The worst was the planning an AI does. When I plan something, it'll be split according to data structures "An object to hold this, an intermediary for the obejct to talk to ORM, a serialiser for it that does this", etc.

The "plans" from SOTA are sometimes just hilarious. It'll go "phase one, implement these user-facing features. Phase two, implement those user-facing features", etc.

That's not a plan, it's an aspiration! A roadmap maybe. A plan, in my way of working, is a blueprint of where all the data goes, with algorithms connecting them. With AI, the data is incidental, the algorithms are incidental, only the goal (in the form of tests) remain. It'll work out some spur-of-the-moment idea around data at the time of writing.

So yeah, I do what you do and throw their stuff away. Currently having more success laying down a skeleton manually and then asking them to add a single feature at a time.

That's with SOTA models as of September-26-2026.

It usually takes me two or three iterations to get there though. Discussing design and principles before writing the bulk of the code is a must. And then a pass or two of review to weed out ugliness.

Still saves time compared to writing the code by hand. Especially for tricky things, where type checking and tests can verify correctness.

There's no clear path moving forward. Overreliance on LLMs means your knowledge will exponentially decay and you will absolutely crash any future tech interviews becoming unemployable. Not using it for some quick wins feels wasteful. Finding balance between the two extremes in addition to all existing software development woes is really hard.

Without them, not only do agents get simple things like function call counts wrong, they tend to return different results. I use this as an example when showing people how the tooling works.

Grep is fine for simple use cases. A step up from that is ast-grep and I need to explore this tool more. But I had the most success building a small pipeline that reads the old code base, parses it file by file using tree sitter, and then loads it into a SQLite database for querying. For example, I have it capture construct definitions and usages and represent those as directed edges and nodes in a single table depending on the node type. The agent is instructed on how to query it and perform interesting queries like build call graphs, or determine dependencies between domains (modularity is not great in this codebase) which is helpful for us to extract around capability lines.

I also calculate fitness statistics, and have some code to capture specific details and knowledge about this very old framework that short circuits agent work in the future. We have some “interesting” magical libraries and functions that block static analyzers from going beyond the call site. This is mitigated, and means agents don’t have to “guess”.

Making all of this available to the different team members at my work has been pretty helpful. It’s faster (fewer tool calls), cheaper (fewer tokens), and accurate.

ive been regularly seeing this exact reaction online since November 2025, sadly :/

Now I can just say "add 2FA" and in 5 minutes, while I test something else, it is done.

It also made iterations a lot faster, you can try something out, see how it feels, if it doesn't work, you can just trash all the code and start again.

Removing the opportunity cost doesn't eliminate the other two costs of a feature

As opposed to writing a prompt for 30s, then doing something else for 15m while the AI works on it? :)

> The real challenge is forming the new ideas in the first place and most of those new ideas coming either from using the code as a product [...]

Exactly.

AI is absolutely excellent at rapid prototyping. Prompt -> result -> use the product -> prompt. Repeat until the right design emerges. Once that happens, the code can be cleaned up, or even rewritten from the grounds up, taking into account what was learned.

I'd expect it's in the tens of thousands, given how effortless you find it.

It always only took a few hours. And yeah, whatever, sure it adds up. But now you've got this dogshit looking flyer outside your restaurant, and it would have taken you like 45 minutes to adept a Canva template.

For AI, the skill loss and all the rest of it, the lack of control, the lack of knowledge of the codebase. It doesn't feel like saving the few hours is ever worth it.

How was this a great experience if what was produced needed such extensive changes that your own assessment is that it should be thrown out? At what point is the necessary rework so much that the thing being reworked didn't really contribute much to the end product at all?

Getting a good writing style out of them requires careful prompting and many corrections, their default writing style(s) are so highly reinforced by training that they will always tend to drift back to them. Maintaining continuity requires you to create a lot of documentation outside of the text itself. It's a much more manual process than working on a codebase where you've set up a lot of automation and tooling that allows them to check their own work.

Edit: it's also worth noting that many LLMs have gotten much worse at writing prose as they have gotten better at writing code.

If you enjoy the craft and the creative process of actually coming up with new thoughts, instead of relying on the probabilistic combinations of thoughts of others, then you can just as well do it yourself and have full control of the process.

I use AI for low value work with dead lines, where the customers don't really care about the result either. For the golden services and customer engagements were I can tell the customer cares deeply, I use little to no AI, and then get a deep sense of fulfillment due to a job well done.

Have you noticed it, too?

Now, manual labor does have its place as a form of art--take high-precision hand-built timepieces for example.

To add some points on he other side of this analogy:

There is not a lot of purely electronic music that has stood the test of time, at least not when it comes to popularity or, more relevant to the metaphor, profitability. There is usually at very least a human voice in the (literal) mix, but more often than not there are also traditional instruments mixed in.

Take this next point as you will as I am being a bit tongue-in-cheek: While making music-making more accessible to more people is totally great, if I could go a week without hearing a variation of the phrase "Check out my dark ambient drone project!" I would feel oddly accomplished.

Most importantly, though:

> But give it a week of practice and most of your skill comes back.. and in 1 month you're back to your peak skill.

This is only true if you had the skill to begin with. For many electronic musicians, by which I mean junior developers, this is not the case. Does it matter? As a 45-year-old traditional musician... er, I mean hand-coder... I think so, but also ¯\_(ツ)_/¯