gbear0 · HackerTrans

2 months agodiscuss

Those checked-in specs become the requirements for the system. So the next time you ask the AI to make a fix, it can use those specs as part of the solution and not break another requirement. Basically the code underneath keeps getting rewritten over and over, but that doesn't matter as long as it hits the required specs.

gbear0

2 months agodiscuss

Why was it a maintenance dead end? It sounds like you were able to iteratively work on it in its current state, but are you going to be the one maintaining the code?

I keep asking myself the same questions, and the conclusion I keep coming to is the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.

There's definitely an efficiency angle here where it's faster for AI to go from a clean modeled solution to the desired solution because it's likely been trained on cleaner code. Is this really going to matter though?

The best argument I can come up with is the clean modeled solution is better for existing development tools because it's less likely to get confused by the patch work of vibes throughout the code; but this feels like it ultimately becomes an efficiency concern as well.

This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.

gbear0

11 months agodiscuss

I've had a similar desire for a code modelling system for decades, so I've given it A LOT of thought, and there has been a lot of older research into Zoomable UIs and Semantic Zoom. Code Bubbles (https://learn.microsoft.com/en-us/shows/alm-summit-2011/code...) is the closest I've seen to the idea, but doesn't cover the scope I want.

Biggest challenge to me is the UX and navigating the relationships between entities (systems, components/modules, classes, functions, read/write memory, etc) requires a lot of design effort around how they work together consistently at all levels. Conceptually, your view is a set of boxes that are a filter/group-by over a lot of entities at some level, and you want to explode only some of those entities. eg. say you want to zoom into a micro-service's component level, but still see external APIs, which could be a single box per API or boxes for each endpoint. So the control you need over the way zooming works and the 'lens' over relationships filter/group-bys can easily become very complex; probably a good research project itself though!

I do think it's possible to build a good interface that would allow viewing from global cloud scale systems and right into the code through multiple paths, like design patterns/components or git repos with files/folders, but I'm not sure how nice it's going to be to use. There's a reason UML modelling didn't stick around. And I'm not sure there's enough of a business case to fund it, but I'll definitely keep hoping to see it some day.

gbear0

5 years agodiscuss

The default editor is usually configurable (of course you'd have to learn all the different contexts you can do this from first to know this is a thing ... discoverability is hard).

For example in ubuntu you can do

  sudo update-alternatives --config editor

Some programs will use the environment variable $EDITOR, so you can add this to your shell startup configs

  export EDITOR=vi

Or specifically for git cli you can run

  git config --global core.editor vi

comments