Hacker News Reader

Comment by atonse | Hacker News Reader

I'm actually curious about using this sort of tool to allow non-devs to make changes to our code.

There are so many content changes or small CSS fixes (anyway you would verify that it was fixed by looking at it visually) where I really don't want to be bothered being involved in the writing of it, but I'm happy to do a code review.

Letting a non-dev see the ticket, start off a coding thing, test if it was fixed, and then just say "yea this looks good" and then I look at the code, seems like good workflow for most of the minor bugs/enhancements in our backlog.

View on HN

Even content changes can require deliberate thought. Any system of decent size is probably going to have upstream/downstream dependencies - adding a field might require other systems to account for it. I guess I can see small CSS changes, but how does the user know when the change is small or "small"?

Perhaps the system could tell them 80% of the time and the reviewer catches the other 20%. An easy heuristic that usually would work in this case is lines of code. It's a classically bad way to measure impact / productivity but it's definitely an indicator and this is probably a rare instance where the measurement would not break efficacy of the metric (Goodhart's law) and might actually improve the situation.

But that's what I mean, when things look small, and are easy to change in the place that it's being asked to be changed, but hidden under the iceberg is a bunch of requirements around that field, things like data stores, or generated pdfs, whether or not that field needs to be added to other calls that aren't in this code base.

yep, reviewers definitely need to be knowledgable about the codebase.

So now you get to manage the business user's expectations. That feedback loop is gonna be fun when they flood the reviewers with requests.

A.I. Assist is probably the ultimate low-code platform. Will it be long before software engineers are replaced?

Assuming you works as a software engineer, is your day actually just filled with writing what could be solved by a low-code platform? Mine certainly isn't.

People will learn about accessibility, multi-platform (mobile/desktop) and many other gotchas real quick.

This almost seems like this is a funnel to force people to become software engineers.

But these are all things that can be added to context by a dev.

Like:

- When making CSS changes, make sure that the code is responsive. Add WCAG 2.0 attributes to any HTML markup.

- When making changes, run <some accessibility linter command> to verify that the changes are valid.

etc.

The non-dev doesn't need to know/care.

There is no robust accessibility linter tool (axe covers only a portion) and you don't want to add ARIA attributes to all HTML markup. Both "accessible" and "responsive" are ultimately subjective, and all code gen tools I've used are more than happy to introduce startling a11y regressions.

It'll probably get there eventually, but today these are not things solvable with context.

Accessibility isn’t something that can be judged by a program, not even close.

> The non-dev doesn't need to know/care.

Yes, they do. Context can't be all-compassing of everything that must be done.

Reply on news.ycombinator.com