"The way that works for you is the right way."
15 packages loaded but only 3 used, `rm(list = ls())` at the top of every script, hard coded paths or worse using the `here` package.
Yubico Authenticator https://github.com/Yubico/yubioath-flutter
I actually don't see any significant signs of AI use. There's Copilot listed in the contributor list, but I'm not seeing commits listed under it. Did they wipe it off Github?
Some seem to stamp Mostly AI based on weaker circumstantial like large init commits. Maybe it's just an artifact of human sloppiness.
Or maybe it was just the artifact of choosing these by last update, since vibe-coded apps genuinely do have an abnormal number of releases, and thus would be much more likely to show up.
I use the contributor graph to find where the AI made the commits [1] and then I search using the date [2], I found 3 commits relative to a11y stuff.
[1] https://github.com/Yubico/yubioath-flutter/graphs/contributo...
[2] https://github.com/Yubico/yubioath-flutter/commits/main/?sin...
That is, the MUAs don’t add "co-authored by myMUA".
At the same time, I think we're far too far down the systems path now. We've hit a point where interviewing has become purely systems design "because the AI writes the code".
Not that I'm ever asked, but I inherently believe the act of critical thinking, communication, and expression are the key skills for those who already have the appropriate coding/engineering/cs/etc background. I now only interview for those skills - but through the lens of impossible to solve systems design conversations as opposed to problems. It tells me a lot about how people think.
1. When you press on someone's design respectfully, do they get defensive. Do they become argumentative.
2. When thoughtfully pointing out a concern, how does the candidate take it?
3. When you suggest a technology that makes no sense to intentionally challenge knowledge, does the candidate recognize why it makes no sense? Are they able to share what the negative of the approach is. If you indicate that you know the question is "senseless" but want their feedback, how do they communicate?
4. When you hard request a change that requires a literal rethink and rewrite do they become argumentative? Do they embrace the change?
5. When discussing testing, how do they think about it? I come down to the nitty gritty and ask about postive vs negative cases, table driven testing, what types of tests matter (for our situation) and why.
6. We discuss timeline tradeoffs, and then have the conversation about the candidate's approach given updates to see how they think.
You'll notice that I am never looking for a solution. I'm seeking communication, description, partnership while having a (relatively) thorough gasp of the subject matter.
Every single time I get a response from a candidate such as "I don't know, I'd have to learn more - or use AI to, or.. what do you think" turns out to be something I LOVE, because it creates a great fabric for the interview.
This isn't the first time I've seen this phrase recently, but I'm not sure what the thought is a cliche or what it is intended to convey (don't read my note as negative, I sincerely am unsure what connotation folks are trying to say).
How many times in your career did you sit down to tackle a task thinking you knew exactly how to approach it only to realize during implementation that there were edge cases you hadn't considered, API contracts that were now broken, or that the feature was trying to solve the wrong problem.
Having to be the one at the helm during implementation made you intimately aware of not only the problem at hand, but the current state of the codebase. That's something you can't replace with automation. You can't compress all of that context into your brain in a handful of prompts with Claude.
Remember the words of your math teacher--
"Watching someone else solve the problem doesn't mean you can now solve it too."
But you effectively lose the human review component.
But ultimately, I think human readability outweighs any theoretical advantage you get from removing a step in the compilation process.
I mean, I'm proud of my low-level skills too but this is some Fabrice Bellard level sorcery. Very, very few humans are able to do this without AI tools.
- is it understandable
- is it maintainable
- how much work is adding new features
- is it written in a way that adding new features means rewriting a lot of it
- is it written in a consistent style
- and lots of other things
I use AI to write a lot of my code, but the only time it's clearly "better" than a competent human is for one-off things.
That being said - AI + human is, without any doubt in my mind, better than either one alone.
Human+AI systems is a good match. Like Human+docs or Human+encyclopedia.
Yes you can ask the agent anything about it and interrogate it until you understand.
- is it maintainable
Yes it’s easy to ask the ai to add new features or to refactor it entirely.
- how much work is adding new features
Depends, it could just be one prompt, it’s usually many prompts. If the refactor is large it can take weeks. But before AI something g equivalent would take months.
- is it written in a way that adding new features means rewriting a lot of it
Usually no, but that depends on how well the agent is being directed and what the features are. If you come up with a feature that requires a new architecture, ai makes it doable rather than saying “would be nice but we’d also have to implement this whole new architecture and that’s a lot of work”
- is it written in a consistent style
Styles can be applied mechanically with linters and formatters, so as much as any codebase written by multiple people.
> Styles can be applied mechanically with linters and formatters, so as much as any codebase written by multiple people.
I'm talking more of a higher level than this - more of coding/design patterns that are common for the team.
I see it be wrong about things all day every day. And yet, IME it's correct enough for it to be controllable. It doesn't have to hold up all of the time, it just has to respond to corrections when they're issued in a loop so that it converges to a correct solution. And it does, despite the mistakes.
In one of my other posts in this thread I detail some of the the ways it's confounded me, but those issues have caused me to harden validation mechanisms rather than say "this thing makes mistakes so I can't use it to write software".
> I'm talking more of a higher level than this - more of coding/design patterns that are common for the team.
Do you have a concrete example?
If we humans are just doing code style checks, file organizing and doc cleanups I feel we have demoted ourselves to code janitors. This is neither fun nor going to last.
Personally I've always strived for minimalism, to find the smallest, fastest, simplest solution possible so I'm pretty jaded now, too...
It did not work properly on Wine nor Windows 10, that was the entire reason for trying it out.
[1]: https://www.pcgamingwiki.com/wiki/The_Settlers_IV
[2]: https://github.com/elishacloud/dxwrapper/wiki/The-Settlers-I...
Just because you don’t seem to be interested in the answer - then don’t read it? - doesn’t make the question wrong.
Agentic engineering faces all kinds of new problems that couldn’t exist before, and need experienced engineers to solve them.
======================================
Hi! I'd like to create an app for interactively learning Chinese using AI. My current idea is:
- The AI generates a Chinese sentence at a specified vocabulary level (e.g. HSK2)
- The user translates the sentence into English, and the AI evaluates the response. If the answer is wrong or is partially correct but could be improved, the AI offers a hint. If correct, the AI confirms and explains any particularly important vocabulary or grammar points that the sentence demonstrates.
- The user should be able to click on an individual character once to see the pinyin, and again to see its definition and any helpful techniques to remember it (radicals, similarity to other characters, visual meaning)
- The app should also be able to go the other way, giving the user an English sentence and having them translate to Chinese.
App details:
- UI is a web app
- The AI should be pluggable. We'll start with a local Ollama install running gemma4, but it should be easily possible to add support for Claude/OpenAI/Gemini or other models (may need to provide an API key).
- Not actually sure if we need a backend. It might be useful to keep track of characters or concepts that the user has difficulty with, or to keep track of what sentences the AI has previously generated so it doesn't become repetitive.
- Build everything in a Docker container (or multiple if needed with docker compose)
””” F-Droid is not hosted in just any data center where commodity hardware is managed by some unknown staff. We worked out a special arrangement so that this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. ”””
I find it strange how little people seem to care these days and just widely share their users and company data across clouds. Plenty of supply chain attacks to learn from.
Separate from building your own code, ,of course you may have your own standards to apply.
But for apps, well, I never had a chance to see how good or bad the code was before AI was about, so why should I care now, so long as what I paid for does what it says it does (and nothing nefarious..)
The blog post provides something akin to answer to this question:
You see, the main allure of LLMs is that they allow the developer to be more lazy. That’s kind of the whole point! You just prompt, sit back and relax. So it should not surprise you to hear that this attitude is then reflected in everything the vibe-coder touches
As I understand it, one of concerns is that with the lowered barriers there comes a flood of low quality software, vibe coded by very lazy and not very talented people.
This might be actually more of a human problem, but it's a problem nevertheless.
I fail to see why worrying about AI code quality is any different to worrying about developer code quality when it comes to pre packaged apps.
With code I am writing, some AI generated, my work load has not really decreased, nor have I gotten lazy. My work has changed to a degree, and now involves reviewing and guiding and double checking AI code where I did not have to before, but I am certainly still working just as hard, and accomplishing more with AI's help in spite of the change in workload it brings.
delivering bad AI code because you got lazy is not the AI fault, it's the developers fault.
I haven't done that at all.
If you're using an LLM to write your code, odds are very high it does not work.
I will be curious to see how I feel about AdventOfCode this year...
Because then why do you ride a vehicle when you could walk?
Why do you use fire when a well-positioned mirror with sun could do?
Why a piezo ignition or lighter when a stick and lots of friction would do as well?
And to the extent they do exist (athletes and survivalists) they might agree there is no "point" except the joy they derive from doing it themselves.
The problem is that formerly there was more alignment between the joy of solving problems with a human's mind and the business need to have problems solved.
If you're doing that, you are producing slop. So it should be called out as slop.
What are the AI smells there?
It would be nice to expand a bit on the reasoning behind the verdicts.
If you're as productive as an engineer in 2016, you're not at the level that's expected. A 7 day workflow back then should take you maybe a day or less to work on today.
It would be too annoying for a human to ever write code to standards this high, and would have taken me months to write by hand, but with the help of AI I was able to get it done and built in a way I can easily review and reason about.
I have a memory safe baremetal tiny linux init now built to my exact requirements.
AI can help experienced engineers write better code in less time.
That is the real difference.
I wrote the first version by hand in C, and then rust.
The LLM was able to rewrite it with no dependencies implementing the low level system calls and test suites that would be a nightmare to do by hand.
The best use of human time for something like this is code review.
I'm working on a validation tool with a coworker right now. We are meat-proxying it into existence, using less than two exchanges per day of his LLM validator and my LLM authoring engine (we could consolidate, but he's got some context I don't have and it would take more than zero engineering effort to ship it to me when PR messages through GitHub are a good-enough channel).
If not for the LLM, the tool wouldn't exist at all because we can't justify dedicating much of any engineering time to building it. But LLMs drive the engineering cost very close to zero, enabling the authorship of code that would never find engineering cycles otherwise.
These are standards of a normal university operating systems course (assuming a university worth its salt anyway). Ridiculous to present it as some kind of feat that was "impossible" or even that rare.
this https://codeberg.org/lrvick/nit/src/branch/main/src/system/r...
is textbook definition of boilerplate. you need to be patient to cross-reference syscall tables but certainly not smart.
Again, students learning about operating systems do similar things as a normal part of their education process.
I'm not saying LLMs wouldn't help with this (in fact, this is the type of thing that becomes pretty much a no-op with them) but the notion that this is "impossible by any realistic standards" is risible, and if you have actually contributed to the kernel like you say, you should know better.
https://codeberg.org/lrvick/nit/src/branch/main/tests/kernel...
That is the point. Getting to results that satisfy security and functionality requirements in much less time.
Also, I was able to generate a bare minimal and hardened kernel config by using the LLM to write a tool to trace all kernel calls. Something that I would have normally been forced to punt on that LLMs made easy to justify.
LLMs are just as Linus Torvalds likes to say "Auto complete on steroids".
How often does "this table of constants was transcribed incorrectly" even come up as a bug class? Is it worth writing a buggy C parser for a failure mode that doesn't happen? Do you expect that Linux is going to change their constant definitions out from under you?
> Do you expect that Linux is going to change their constant definitions out from under you
Unlikely but I have been surprised before. Hardcoding to pretty much any modern kernel source version forever for this narrow use case is probably fine.
The goal is about helping me and a reviewer quickly form confidence none of the magic numbers are mistaken or malicious in an automated way against the source of truth.
What does that mean? Are you building a system without a root user or something?
I design confidential compute systems.
That makes you a) more unique than you realize b) not all that relevant in the context of the article.
a) Because a lot of people tend to lean towards use that absolutely leads to atrophying of skills and knowledge. b) well the article does explain the criteria it used fairly well and your project would not show up there. Well, also because your project isn't an android app.
Android apps on the other hand, LLMs have enough training data to rapidly generate whatever you can think of with much less time required for an experienced engineer to refine it into a quality result.
I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.
It is frankly amazing we can point an LLM at a proprietary ad-ridden app and get to an ad-free open source and privacy respecting clone in a weekend now.
Its not that hard to imagine that apps made with heavily LLM involvement suffer in quality. The article already goes into it a bit. I get the strong feeling that you are failing to approach this from anything else than your own perspective and how you use LLMs. Which, given the setup you are describing is already far from the norm.
Zooming out a bit further I think we can generally break up LLM usage in roughly two distinct ways of using LLMs. Or maybe more accurately there are two sides of a spectrum with a lot of area in between them:
1. Let LLMs do the majority of the heavy lifting and generate the output. Providing an LLM with some basic info, what you are looking for and let the LLM do most of the work for you. 2. Using LLMs as a tool external to the process where you are still doing most of the work.
The first way of using LLMs using agentic workflows, code harnesses, etc *can* produce good quality. As long as there is still a human in the mix who a) has the prerequisite knowledge to validate what the LLMs have generated b) takes their due diligence at key points in the process to actually make sure input is of high enough quality and validates the output.
You have decades of knowledge and experience you are now applying to rigidly structure how these LLMs work. Which, yes again, I believe gives you personally pretty good results, no doubt about that. But, many people do not have that experience to begin with. And even for those that do, using the first method comes with a risk that boils down to simple psychology, our minds are wired to take the easy approach wherever they can. Which turns the first way of using LLMS from a efficient way of using them to a lazy way of using them.
In my personal experience a lot of people who start using LLMs sort of drift to the lazy approach very easily. Because it is very convenient and easy to slowly hand over more thinking to an LLM. The latter I have seen happen all too often around me. An alarming increase of lazy non critical use of LLM tools by people who should know better. People who might have been a bit slower before but delivered excellent results now have started delivering trash. Code spanning dozens of line trying to solve something that should only take one line. Code that completely ignores and conventions or design paradigms put in place. Code that goes directly against security practices. Suddenly downgraded dependency versions (because the models training data doesn't include the latest version).
As I said, I see this as a spectrum and the more someone leans towards the first use case combined with "lazy usage" the more signs there will be in a repository that this is the case. The amount of commits, the release cadence and various other things. Which, again, the article also makes a case for and is again why your repository is irrelevant to the whole discussion. Why? Because your repository doesn't show these signs.
LLMs help experienced engineers write quality code faster and it helps amateurs write shit code faster. Problem is there are simply way more of the latter. Even so I detest engineering being judged by the tools used, instead of the work itself being judged on its own merits because there are exceptions to every rule. I would like to teach people to use these tools responsibly, instead of sending a message that use of these tools is automatically thoughtless slop.
Like, most people I know that use Vim write much higher quality code on average than the people that use VSCode as tool preferences often reflect experience, but not always! It would still be unfair to write off someone's code sight unseen because they used VSCode as there are always exceptions to the rule.
LLMs also helps inexperienced engineers (or people who do not have any own software engineering skills themselves) to write horrible code in less time.
Of course you also can't trust everything human developers publish either, but the issue is amplified by LLMs.
Well, that is true, but I have seen how one japanese developer, who has had low english language skills, suddenly writes epic text. So it is clear that he is using AI when interacting with other people. This is a problem because a lot of it is just AI slop fake interacting. I don't want to interact through any AI filter; it means the other human being is not interested in communicating with me, so why would I want to communicate with an AI slop controlled human? It makes no sense.
As for software: IMO documentation is very important. Many projects lack good documentation. This is valid for both AI slop created projects and real humans created projects. There are too many software developers who hate writing documentation. I don't want to use such software anymore.
Unfortunately AI slop documentation often sucks too. They just spam you down with words that mean nothing. And are very verbose. This is also totally useless.
It seems as if software designers indeed fail hard in the last years. Quality standards used to be higher in, say, 2005 to 2010, compared to now and the last five years.
> Their mere existence makes educating yourself and going on fun side projects much less rewarding.
It's not just AI though. Look at Google search. Use it. It is totally useless now. Google crippled it deliberately some years ago. Now you'd think alternatives are better, but they also suck. DuckDuckGo? Qwant? They, oddly enough, manage to be even worse crap than Google search, which is amazing. Crapification has become the default now.
Everything these days is shell scripts! They are even selling them like they have the same value as a C program! csh will never be real C. The kids have no idea what a stack is or how to optimize system calls. The performance is awful and they barely work! The way scripts spawn processes can bring a multi-user terminal system to its knees!
I mean, sure, I write some scripts now and then, but the real logic always goes in C. And just the other day my boss gave me a shell script he coded over the weekend and said putting it in production should be easy!
Over the weekend I was checking out BSD and I couldn't believe the number of scripts I found. I fear for the future of my career and computer science in general. Our field might die out before it can even get off the ground.
The authors are sharing their creativity, and spending time & money to publish apps with a free license.
I have disdain for how entitled open source consumers are. Before AI, demanding free accounts, support , resources, traffic, cpu -- after AI demanding bespoke hand-written code be given out for free.
Well no, they are exactly not doing that but pretending that they are.
More here: