I've always been a bottom-up programmer, so I tend to think more about discrete operations of software rather than the user-facing features (which IME will fall out naturally).
1. Experiment and solidify architecture before adding features. I think this is the hardest step for top-down thinkers.
2. Heavy testing and benchmarking. Prefer to TDD as much as possible. The actual lines for my agent-written codebases are generally ~70+% tests, benchmarks, and experiments.
3. Full mutation test coverage after the code is written. Doing this as a human is miserable IMO, but robots make it reasonable. This step resolves SO MANY subtle bugs.
At that point my main role is ensuring alignment with the actual specs.
Yeah I feel like what you say makes sense. Part of my issue comes from the fact that we're a pre-PMF startup, so rapid experimentation and prototyping really matters at the moment with very little room left for deep thought around testing and benchmarking.
The trouble comes later when the "experimental features" actually start getting traction and we discover all the holes in our implementation.
By the time we need to "productionize" our experiment, it has already been patched all over the place to account for bugs.
I get a feeling that this is made worse by the fact that since a lot of what we're doing is rapid prototyping, our repo is cluttered with examples of bad code that the agent picks up on and then goes ahead to copy in its own implementation.
I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
One of my mantras is 'fast is the best UX'. Users will put up with minor annoyances as long as they're over with quickly. Once you fix the annoyances, you're still fast, which leads to User Delight.
> I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
Enumerate, then fix-or-nix all known examples of bad code first. If you clear the path first, you will advance more quickly. It can feel frustrating having to do that, but my experience is that paying off tech debt earlier will prevent hitting the wall at an inopportune time.
I think this is a certainty. Future generations will be born into a world where education, technology, and jobs have corrected for AI's existence. They will never know a world without it or have the experience of the current growing pains.
We've seen this plenty of times with new tech in the past, and as disruptive as AI is, I can't imagine the cat going back in the bag.
Its a bit like how we have gps connected maps in our pockets. Anyone born after 2000 has only a loose concept of being lost (within range of a *G tower and >1% battery) and treats paper maps as a hobby. Our children will grow up assuming their phone can do maths and programming better than human ever could.
>In five years, we'll all have phones that connect physical locations again, instead of (or as well as) people. And we'll be raising a generation of kids who don't know what it is to be lost, to not know where you are and how to get to some desired destination from wherever that is.
>Think about that. "Being lost" has been part of the human experience ever since our hominid ancestors were knuckle-walking around the plains of Africa. And we're going to lose it — at least, we're going to make it as unusual an experience as finding yourself out in public without your underpants.
Heya - I'm the author. Glass is a cross-platform MCP server that gives an agent a way to see and interact with GUI apps. I don't
like building UI. Agents can code it, but can't verify or debug it.
Glass exists to close that loop.
Glass is purpose-built for software development, and aims to enable headless, parallelized agent work while
the user continues to use the machine unhindered[0]. It minimizes token usage, increases consistency, and just goes faster
by preferring to interact with an app's accessibility tree, before taking the screenshot route (which glass also fully supports).
Glass is cross-platform and the code is Apache-2.0 licensed. We release builds for Linux, Windows, and macOS hosts.
Glass supports development targeting the three above host platforms, Android (all hosts) and iOS[1] (macOS hosts). The
internal API is backend-agnostic, and new platforms can be added in the future pretty easily.
Feedback is very welcome, either here or at github. If it breaks on your app, I am especially interested in
knowing about that. I hope you build great things.
[0] Due to the license enforcement on Windows and macOS, isolated headless development targeting those
platforms requires a VM. It will otherwise interact directly with the desktop.
Android and iOS development on those platforms can still be done headlessly via the emulators.
[1] The iOS backend does not currently support multi-touch gestures.
Having good error messages is one of the important priorities for me in my compiler, so I made the commitment early and am using codespan_reporting[0] to report the errors, which is going well so far.
My understanding is that he was looking for instances of TypeError, AttributeError, undefined is not a function and so on. So yeah, nulls should've been included.
1. Experiment and solidify architecture before adding features. I think this is the hardest step for top-down thinkers.
2. Heavy testing and benchmarking. Prefer to TDD as much as possible. The actual lines for my agent-written codebases are generally ~70+% tests, benchmarks, and experiments.
3. Full mutation test coverage after the code is written. Doing this as a human is miserable IMO, but robots make it reasonable. This step resolves SO MANY subtle bugs.
At that point my main role is ensuring alignment with the actual specs.
reply