I've never been more informed or understood more about my code, pipelines, and stack than now- and its 100% due to AI reasoning about my projects, and me making an effort to learn.

I'll add this link to the pile: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-too...

> spec-kit created a LOT of markdown files for me to review. They were repetitive, both with each other, and with the code that already existed. Some contained code already. Overall they were just very verbose and tedious to review. [...] To be honest, I’d rather review code than all these markdown files.

The hardest part of any of this extraction is that modern code is already an extremely dense representation of how the computer should work. You mostly can't change the code without changing behavior.

I bet Scryer works for his use case, and it's a joy to dogfood. I also bet it fully breaks down the moment a 2nd developer, who cares about different things, joins the team.

I scanned the article, never made it to the bottom, didn’t find the point the author was trying to make.

Howabout just learning to code better as a human without using AI. Just like learning a craft. Just refuse to use AI. Not possible because of peer pressure? Well then stop worrying and continue to vibe.

Either stop or stop complaining but don’t make excuses or write long articles that ramble and rant … sorry but I don’t understand what’s so hard about stopping.

That sentence is probably the key.

There is zero chance of this stopping overall.

Much like with artists 90% of the commercial stuff - copy/ads with generic guy in suit picture - will be AI that is "good enough".

Less concerned about the code quality and more the labour market dynamics. If this goes anything like translation & creative space did then there is going to be a brutal shakeup where competition for remaining "real" seats gets intense

I'd really like something that works more like pair programming. Where you share an editor session with the AI, and it's much more interactive. eg. It says "I'm thinking about doing X here, what do you think?". Then you give a response and it continues. Or you can see it doing something silly and immediately stop it and correct something either with a prompt or by manually editing yourself, before letting it rip again. Or just ask it "why are you doing it that way?". Maybe with some control over the speed it's going, for when you feel confident about what it's doing.

Claude has made some positive changes over time where it asks you more when there are different approaches it can take. But I feel like I'm not being brought along with my mental model as much as I would like. A lot of the time it spits out a whole pile of code and then I have to go and build up the mental model after the fact, and correct a lot of what it's done.

The current approach is good a lot of the time though, when you're not really changing anything architectural and just want it to bash out code while you do somehthing else.

I started on Pascal and C/C++. Then I moved to Python. It freed my mind from types, and I was able to think more high-level about the data structures.

After another decade and half, I discovered Haskell. Turns out the types were not the problem; the lack of proper type inference was.

So it turned out to be a usability issue of C/C++. Writing type explicitly everywhere is just bad UX.

My point is this. LLM's allow you to program and reason about code in a natural language. It clearly has some advantages over programming in traditional programming languages. But it has a significant disadvantage that natural language is not semantically sound. (And as a result, you get what people incorrectly call indeterminism of LLMs.)

I believe we need better programming language in which we can also express metalogical properties of programs, as if we expressed them in natural language, but with soundness guarantees. This new language would then become the new source code.

This language needs to have primitives for fuzzy and modal logic, and there need to be some algorithm that can typecheck (check if the statement is consistent) and type-infer (if the statement is inconsistent or ambigous, fill-in the likely parts, possibly interactively).

We know such a formal system must exists, because a very close variant of it has already been implemented (or discovered?) within LLM.

We essentially need to discover true metaprogramming - writing programs that manipulate programs. From Curry-Howard isomorphism, we know there is analogy between program execution and reasoning. So it is time to start using same language for both. (I am looking into using Triage Calculus for this.)

1. malware development

2. anything security tooling related

3. reliable assembly

4. reliable and somewhat more obscure programming languages like blockchain programming langs or distributed programming with elixir

I feel that https://maldevacademy.com has been keeping my skills relatively fresh, it's fun in the discord where sometimes we try using models to do this stuff and it just chokes

On the other hand I "vibe coded" (Although I've heard more nuanced distinctions in terminology here about doing it right rather than just letting it rip automatically or without much thought) a fairly large and profitable software project in about a month recently that would have probably taken me over three if I hadn't used claude.

In the end and as you mentioned, these things are just tools and if you're busy complaining about them rather than finding what they can't do yet and having a bit of fun with working within those limits, you might be able to find a good niche to make better use of your time and avoid the skill atrophy

I can instrument to observe the instructions being executed.

* Delegation

* Execution (better rules than rtk)

* Response

* Logging

When I want to turn off the printf style confirmations, manually editing saves the tokens. Using RFC 2119 (language) doesn't make a substantial difference. I'm in search of something better.

Speak for yourself. If anything is leading _me_ to burnout, it's this bullshit hype cycle.

That said, I don't understand why it seems like it has to be all or nothing. Just architect the software yourself and tell the LLM to modify small chunks of code that you understand. Or maybe not even small, but a body of code where you understand what it does and can understand what the LLM is changing. Don't tell it to implement a feature - tell it to implement a function. If you can't do this, then you're a wannabe who's using LLMs to LARP as an actual programmer.