Maybe a tangent, but I've gotten a lot of the joy back with 3D printing. You can just describe something, and Astra can model it in CAD extremely well. It usually takes a few iterations, and then you can just print it. I found that before, it would take days to build even simple models in Tinkercad - which while fun, was high enough friction that a lot of things would stay in the "ideas" folder - now I can have something real in an hour or two.
But I think it's really about finding the right abstraction. As a staff or principle engineer in the beforetimes, I also didn't understand most of the code being written by the org. I dove in where needed, but more importantly I found the right layer to understand what was going on - dependencies between teams and services, data flows and data models, etc. And where I found myself most effective was when I was shaping and understanding those effectively.
I don't know. We've managed to avoid most of this, I think. We have tech debt, but it feels more like regular tech debt than sloppy engineering practices. What's worked for us:
- Very strict linting, type checking, and so on.
- An opinionated flow of data and clear layers in the codebase.
- Good code review workflows with multiple AI code reviewers, along with a pretty opinionated SDLC.
- Agents that look for duplication and opportunities to simplify.
- Strong opinions about our core data model.
I really think that the companies that are struggling with slop probably struggled with slop before. It just moved slow enough that things could be fixed.
I don't understand this slop debt either. I make lots of small changes, as I did before, alongside self-reviews. This time, the AI puts together the PR and helps with reviews.
> Slop debt comes from a lack of decision. Nobody chose the variable names, the error handling pattern, or the layer of indirection that does nothing.
Ofc people agreed on these things (and avoided the last one) because our teams do proper objective reviews.
> You open a file to fix a bug and find three different retry strategies, two different logging conventions, and a helper function that duplicates a standard library method for no discoverable reason.
Our team literally used AI to remove this duplication. It's very good at it.
> Slop debt resists this because it is everywhere at once, at low intensity. There is no single module you can point to and say, this is where the debt lives. It is smeared evenly across the whole codebase, a little bit of incoherence in every file.
This is pure FUD. Automated consistency will out perform manual consistency at scale and over a long period of time. This is statistically relevant and one of the many things AI is helpful with.
I still don't understand what the "debt" here is supposed to mean and this seems like the same anti-AI hand waving I've been seeing all year. Probably aimed at people who are vibe coding entire projects or modules, I assume.
It's my own ignorance speaking, but is this as true in math? I could see this being a problem for programs where you have few, if any, real axioms and the axioms themselves change. But if we're talking math, the axioms should be fixed.
Most math does proofs somewhat informally (as in the proofs are written in a conversational style, and they're considered valid when they convince the majority of mathemeticians), but those proofs can be traced back to ZFC (a specific formulation of set theory and first order logic).
Type theory, especially dependant types, are a pretty recent development, and aren't really used in practice in math. Even in Mathlib (what most people mean when they say they've used lean), they encode first order logic. The proofs are dependently typed, but the actual logic of the proof is all in ZFC.
For what it's worth, I really enjoy superpowers. In particular, it does a great job with TDD that stops the model from jumping to conclusions, and I've been able to get it, even with Opus, to execute on much longer specs quite well.
In addition to what other people have said, I've taken some time to do leetcode questions lately - both architecture ones and coding ones. I'm not looking for a job by any stretch, but the practice and forcing a detailed zoom in has been really cathartic, and leetcode gives a nice structure/feeling of progress to it.
Agreed. I am impressed by both the satire of this, and the very high-quality implementation. It is so well executed, that it is hard to laugh at the absurdity of the lemmings-like patterns modern AI start-ups have fallen into.
At first I had a good chuckle of “this really encapsulates the tropes, even down to being React” and the more I scrolled through the components, it looks like a very serious library - lots of knobs to turn and consideration for various implementations!
I was going to say that too. Some of these I definitely am guilty of. I have a few dozen that aren't on the list but it's a breath of fresh air to see it so well organized even though, we all know what it is :D fantastic job to the author(s).
This will be really powerful for voice. Being able to reason makes LLM so much smarter but with voice your latency budget is so tight that you can't spare the time typically.
reply