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.
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).
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.
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.
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...
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?
It did not work properly on Wine nor Windows 10, that was the entire reason for trying it out.
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.
They don’t make normal mistakes like typos and they aren’t lazy so things like tests and checking error cases is usually done.
Now, my entire programming flow does not even include an editor. The tools I use are: pi.dev to write and implement openspec specifications, herdr to manage many pi instances, and ollama to run qwen 3.8 27b on my single 7900 XTX.
Writing good specifications is the key detail here. I will often iterate on a spec for hours until I am happy with it all of the details. Once I am happy with the spec, I can be quite confident that when I tell pi to apply the spec, the changes that I want will be done, and done how I want them, when I come back to check when it reports itself as done.
The landscale is fundamentally different from what it was. Feel free to ignore it, but you can absolutely generate high quality code if you know what you're doing.
But I all but stopped writing code 13 months ago. At the beginning the code was often bad.
In the last 6 months alone I had received more praise from my customers for excellent work than ever before.
LLM is incredibly valuable for debugging complex problems, codebase exploration, and planning large changes. But the writing code part itself, I find, LLMs are just not very good at it yet.
Vaguely telling the agent what the issue is and what behavior I expect solves the issue with a fraction of the effort.
Some claim that the tech debt only keeps increasing and that the result will be unmaintainable. This is not my experience, and I don't think it is theirs either. These claims are often entirely speculative.
I doubt that any supposed future extra effort for the AI to add new code is remotely comparable to the upfront effort of you reviewing the code manually.
I know that this is the case today for native mobile apps, and I speak from hundreds of hours of experience over the last four months on such a project where I stopped reviewing the code.
We are already here today, and this balance is only going to further shift to the point where it is obvious that the hands-on approach is no longer competitive.
And neither one of those statements is very convincing to me.
Anyway, I think we shared our viewpoints, and neither of us is going to change their mind until either my project fails spectacularly, or you change your approach in the future to use AI more autonomously.
FWIW, I've also had bugs the agent fixed that I probably never would've figured out without LLMs - LLMs are definitely useful! But I need to keep understanding how the code works so I can take over the reigns when the LLM fails.
Without such prompting and a conciseness and clarity pass you get a slop grenade.
They overall work better with tests, and Rust is a great language for them. Overall they do better with lots of walls and alarms that go off if they mess up. I don’t need nearly as much of this, can mentally simulate it, which is a good “are we superintelligence yet” reality check. Still not even as good as my wet meat brain. But impressive given what was possible even two years ago!
The result is still not as clean as a good programmer but it’s better than the slop grenade you get first pass.
GPT 5.6 sol and Astra can now one shot incredible stuff.
The solution required reverse engineering and internals knowledge that most human engineers don't even have.
The question is no longer "Can an LLM write code?". It can. The problem is that certain humans refuse to put in the effort required to properly utilize these tools.
LLMs as things that know what's in the manual are AAA+. Extremely helpful. Very good at making a rough draft of something filled with a lot of stupid mistakes and no new abstractions. That's what your transparent window thing is. Something that you could never ship, is probably too big and doing senseless things for no intelligible reason, and definitely has bizarre bugs.
This application, named Seymore, is being evaluated for purchase by several tech companies. (It helps having good industry contacts)
There was a ton of interesting engineering required to make this work at 60 fps+ without resorting to hacks or using private APIs. Most macOS engineers wouldn't even know where to start.
I've shipped code that is used by billions of people and all you just did was spew a bunch of bullshit. As someone who has built their own LLM from scratch, I have an extremely good idea of what they can and can't do.
If you don't know how to use these tools, you'll end up with crap. If you DO know how to use them, they are incredibly useful.
What they are saying is increasingly difficult to defend, but they will do it anyways. I see the same arguments at my job, and I just gave up arguing against
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.
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".
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.
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.
What are the AI smells there?
It would be nice to expand a bit on the reasoning behind the verdicts.
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?
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.
””” 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.
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.
> Make no mistakes
Don't forget the copium!