And that's also a decent barometer for what it's good at. The more amount of critical assumptions AI needs to make, the less likely it is to make good ones.

For instance, when building a heat map, I don't have to get specific at all because the amount of consequential assumptions it needs to make is slim. I don't care or can change the colors, or the label placement.

But it's not all bad news. TIL about Parameters<T>.

So you do agree? If you are having to review and correct then it's not really the LLM writing it anymore. I have little doubt that you can write good Typescript, but that's not what I said. I said LLMs cannot write good Typescript and it seems you agree given your purported actions towards it. Which is quite unlike some other languages where LLMs write good code all the time — no hand holding necessary.

What else would you need to correct? I've never had trouble with LLMs generating basic syntax in any language. Architecture is exactly the aspect of language where LLMs seem to like to go to crazytown when in Typescript. It seems you've noticed too if the ideas in that area have had to come all from you.

Exactly. You can write good Typescript, no doubt, but LLMs cannot. This is not like some other languages where LLM generated code is actually consistently good without needing to become the author.

If you set up restrictive linters and don't explicitly prohibit agents from adding inline allows, most LOC will be allow comments.

Based on this learning, I've decided to prohibit any inline allows. And then agents started doing very questionable things to satisfy clippy.

Recent example:

- Claude set up a test support module so that it could reuse things. Since this was not used in all tests, rust complained about dead_code. Instead of making it work, claude decided to remove test support module and just... blow up each test.

If you enable thinking summaries, you'll always see agent saying something like: "I need to be pragmatic", which is the right choice 50% of the time.

Then use ideation to architect, dive into details and tell the AI exactly what your choices are, how certain methods should be called, how logging and observability should be setup, what language to use, type checking, coding style (configure ruthless linting and formatting before you write a single line of code), what testing methodology, framework, unit, integration, e2e. Database, changes you will handle migrations, as much as possible so the AI is as confined as possible to how you would do it.

Then, create a plan file, have it manage it like a task list, and implement in parts, before starting it needs to present you a plan, in it you will notice it will make mistakes, misunderstand some things that you may me didn’t clarify before, or it will just forget. You add to AGENTS.md or whatever, make changes to the ai’s plan, tell it to update the plan.md and when satisfied, proceed.

After done, review the code. You will notice there is always something to fix. Hardcoded variables, a sql migration with seed data that should actually not be a migration, just generally crazy stuff.

The worst is that the AI is always very loose on requirements. You will notice all its fields are nullable, records have little to no validation, you report an error when testing and it tried to solve it with an brittle async solution, like LISTEN/NOTIFY or a callback instead of doing the architecturally correct solution. Things that at scale are hell to debug, especially if you did not write the code.

If you do this and iterate you will gradually end up with a solid harness and you will need to review less.

Then port it to other projects.

Sounds like a solid way to make crud web apps though.

Holier than thou “yeah well I work on stuff that doesn’t use databases, checkmate!” doesn’t really land - data still gets moved around somehow, and often over a network!

For that I usually get it reviewed by LLMs first, before reviewing it myself.

Same model, but clean session, different models from different providers. And multiple (at least 2) automated rounds of review -> triage by the implementing session -> addressing + reasons for deferring / ignoring deferred / ignored feedbacks -> review -> triage by the implementing session -> …

Works wonders.

Committing the initial spec / plan also helps the reviewers compare the actual implementation to what was planned. Didn’t expect it, but it’s worked nicely.

Personally, I think it's just the natural flow when you're starting out. If he keeps going, his opinion is going to change and as he gets to know it better, he'll likely go more and more towards vibecoding again.

It's hard to say why, but you get better at it. Even if it's really hard to really put into words why

Its not random that AI happens to be built by the very same people that turned internet forums into the most addictive communication technology ever.

It may actually be true. Your feeling might be right - but I strongly caution you against trusting that feeling until you can explain it. Something you can’t explain is something you don’t understand.

have you ever learned a skill? Like carving, singing, playing guitar, playing a video game, anything?

It's easy to get better at it without understanding why you're better at it. As a matter of fact, very very few people master the discipline enough to be able to grasp the reason for why they're actually better

Most people just come up with random shit which may or may not be related. Which I just abstained from.

This is something everyone who cares about improving in a skill does regularly - examine their improvement, the reasons behind it, and how to add to them. That’s the basis of self-driven learning.

And that's not really explainable without exploring specific examples. And now we're in thousands of words of explanation territory, hence my decision to say it's hard to put it into words.

For instance, if I say “I noticed I run better in my blue shoes than my red shoes” I did not learn anything. If I examine my shoes and notice that my blue shoes have a cushioned sole, while my red shoes are flat, I can combine that with thinking about how I run and learn that cushioned soles cause less fatigue to the muscles in my feet and ankles.

The reason the difference matters is because if I don’t do the learning step, when buy another pair of blue shoes but they’re flat soled, I’m back to square one.

Back to the real scenario, if you hold on to your ungrounded intuition re what tricks and phrasing work without understanding why, you may find those don’t work at all on a new model version or when forced to change to a different product due to price, insolvency, etc.

Pursued far enough, any line of thought will reach something non-deterministic - or, simply, That's The Way It Is - however unsatisfying that is to those of us who crave straightforward answers. Like it or not, our ground truth as human beings ultimately rests on intuition. (Feel free to say, "No, it's physics", or "No, it's maths", but I'll ask you if you're doing those calculations in your head as you run!)

If you want to say "god is responsible for creating the precipitation cycle", sure. But we don't disregard understanding that exists to substitute intuition.

Yeah, "God did it" is the first of those answer layers at which some people stop interrogating the world around them, just like "that's just the way I am" is where some people stop developing their self-understanding. Neither of those answers advance civilization / ourselves any further than the status quo. They're terrible answers! Everyone should be digging deeper.

However, I would not use the word "understanding" in opposition to "intuition". Someone who can generate a ballistics chart understands trajectories, but so does someone who can reliably put a basketball through a hoop or a bullet on target. I would set "analysis" against "intuition" (or "instinct", if you prefer), but they're not in opposition: instead, they reinforce each other. We're all familiar with the scientists and mathematicians who ride a hunch to a ground-breaking discovery, which is then validated by exhaustive analysis. From the other direction, athletes and musicians analyze their technique in minute detail, and practice incessantly, in order to ingrain analytical insights into instinct. (Or, if you prefer a less physical example, programmers study algorithms so that they can intuit which to apply to a particular problem.)

My point - badly expressed in my earlier comment - is that as humans we exist moment-by-moment, and as such react, in each moment, by intuition. As important as analysis is, we cannot live in analytical mode: it lags too much! Furthermore, approximately none of us will ever make a groundbreaking discovery in any field, far less in all of the areas to which we can (and should!) direct our analytical energy. At some point we have to stop (even if we are a groundbreaking genius in one area, we'll have to in all of the others), and accept the answer that satisfys our purpose or exhausts our motivation.

You are just making stuff up or regurgitating material from a pop science book.

Please explain walking to me so that I can explain it to a person who forgot how to walk such that he can walk after the explanation.

Mind you, I don't think the process of improvement in those dimensions is fundamentally different, just much less direct and not easily (or perhaps even at all) articulable.

I think "more and more" is doing some very heavy lifting here. On the surface it reads like "a lot" to many people, I think, which is why this is hard to read without cringing a bit. Read like that it comes off as "It's very addictive and eventually you get lulled into accepting nonsense again, except I haven't realized that's what's happening".

But the truth is that this comment really relies entirely on what "more and more" means here.

This should be done on day one with a company-wide skill or project template that defines hard limits and processes for the Agent.

Strict linters, formatters and code quality checks are essential to de-slopify the code as much as possible.

That doesn't fix bad design though, that's still on humans.