-​-dangerously-skip-reading-code

One agent generates : Spec -> Code then

Another agent: Code -> Inverted Spec

then compare Spec and Inverted Spec.

If there is a Gap, a Human fixes and clarifies the Gap.

This is like Generator and Discriminator aspects of GAN models or Autoencoder models.

Yes. It would be like buying a car that you have no idea about the engine and gearbox and kind of fuel it is using or if at all. It have four wheels and and it can drive you from point A to B. Sure but sometimes it happens that some particular brands and they particular model requires engine renovation after 100k km because it is so shitty design.

Right now we are just starting vibe coded software, nobody knows how it will behave in 2 years or 5 or 10. My guess it won't. So we will enter age of scratch software. You build it, ship it. And after few months you will ship entirely new one. And then again. And again. And again. Because maintenance is hard and costly and writing from scratch will cost like 1k$ in tokens.

And users will have problem of migrating the data if possible at all. But if migration is hard and everything changes all the time does it even matter if you are using X o Y software? Does it even matter since you can write your own software and migrate your data there?

I think we saw how this ends with Chinese manufacturing. You buy some stuff from AliExpress for 2$ and throw it away in two weeks and buy a new one. So quality does not matter anymore.

it's the most honest framing I've seen, but specs as the new source of truth is exactly what we promised ourselves with UML, then WSDL, then OpenAPI. the graveyard of just make the artifact above the code authoritative is long

For sure every time you use ai you’re sacrificing understanding if you don’t plan out and understand how exactly the ai is going to do the work you asked it to do.

The same output that is such a bad thing in this article can also be used to gain context, by making a thorough plan with your ai first, reading through the plan and proposing changes just like you would with a real developer.

You can also use this output to have the ai write a journal as well. The journal can be as detailed as possible and essentially a ledger of all of the changes your ai has made to the code. This allows not only for your teammates reviewing your pr to gain greater context, but also can be used by yourself, or even the ai itself to figure the why behind a particular implementation was done the way it was, far into the future even.

Lastly how many of us ever deploy code without actually checking the feature works e2e? I would gather not many of us do, I don’t, because even though we may have a greater understanding of the code, we can make mistakes in the code or in our logic. And I keep coming back to why would we treat llms any differently? I believe we should be spending our energy thoroughly manually testing a feature to make sure when we brainstormed we actually did get every edge case, and it works well.

I prefer "the bottleneck is understanding" framing.

The author is nibbling at the same problem ultimately, but i don't think "hey one strategy is we could just let cognitive debt accumulate so we can go faster!" is a particularly insightful tool in the toolbox. Don't misread me, i'm not denying it can be a valid strategy.

Instead i want to read about insightful strategies for optimising that system-wide bottleneck we have: understanding.

Tell me about how you managed to shift to a higher level of abstraction, tell me about how and when that abstraction leaks. Tell me how you reduced the amount of information that has to flow through the system bottleneck.