Exactly this! Many times I read an article that someone says is "obviously AI" and lists several tell tale signs, but these are patterns I also follow in my own writing. I guess that makes me an LLM? These are patterns I was taught for years in school, both in high school and in college level technical writing classes. They may be tropes - or rather patterns - but that's because they were taught en masse to students across North America. Like you said, to really sound like an average person, the answer would be to write in an inconsistent, meandering way full of logical fallacies.

There was a vote to block it and the vote failed to pass, hence they failed to block it.

The they failed part is not the Senate. Some members of the Senate failed to get the votes to pass the bill. Whe. You say it like you have it implies the will of the senate was to block it and they failed. And that is weird because the senate clearly did not want to block it otherwise it would have been blocked.

The senate rejected the bill. They did not fail to do anything. The bill failed to get the approval of the senate.

But one thing we know. In the senate did not fail.

The Senate could have failed only if they intended to do something, but then couldn't do it.

> The Senate could have failed only if they intended to do something, but then couldn't do it.

They, meaning a large number of senators, intended to do something, and then couldn't do it. This is the standard way every resolution which does not pass is described.

I haven't seen AI systems do this in my experience unless you specifically ask for it. Sometimes the outcomes can be a bit complex, but I find myself having to prompt it specifically when I want something more abstract.

This is interesting because I specifically look for the opposite in interviews and design reviews. Yes, sometimes complexity is needed to handle scaling, extensibility, observability, security, and privacy, but most of the time it doesn't. I have new engineers who jump to designing big complicated modular systems with multiple levels of abstraction and I have to tell them to slow down and try something simpler. YAGNI is a real consideration.

My principal is: you don't have to do it right now, but make sure you could do it if you need to. This mainly comes down to avoiding assumptions. Simplifying assumptions can make things easier, but designs that don't leave room for extension make it really difficult to add those things later. It's a difficult balancing act, but I greatly appreciate any engineer who recognizes it and can manage it.

While that will always be true, LLMs do it a lot more often and do so with confidence and poise. We have evolved ways to tell if someone is making shit up (which usually works); LLMs subvert this. We are also being sold the idea that these LLMs are some kind of super intelligence which isn't helping matters.

Wouldn't a weekly reminder if your calendar do this? I don't see how an agent improves this.

I don't get it either. I even sat down to try it out and see what it's all about, but I can't think of a single thing in my life that I want an agent to automate.

Summarizing news? No, I'd rather just read it. Besides, it's hard to say what will or won't be interesting at any given moment.

Reply to emails? No, I want to make sure I say what I mean to say and I don't see why I would tell the whole story to an LLM just so it could rephrase it all.

Trade stocks? Dear God no! That's a good way to lose my life savings, and if the solution is to just put in a little then what's the point?

Every video and post I see talking about all the things they have automated with agents are things I would never want. Most of them describe content farms - look at what's hot on Twitter, generate a video, post to Reddit, etc. Others like preparing a morning summary are neat and all but so what? If my life was so hectic that I needed a personal assistant to take my calls and book my meetings, I'd hire one.

Seriously, what is the thing that agents can do that every ordinary person just can't live without?

One supposition I see in this and so many other articles is that using AI to generate code results in not knowing how it works. I believe that's only true for "vibe coding", not for engineers using AI to generate code. The difference is in how much you plan, design, and specify upfront.

If you give an AI a very general prompt to make an app that does X, it could build that in any imaginable way. Someone who doesn't know how these things are done wouldn't understand what way was chosen and the trade-offs involved. If they don't even look at the code, they have no idea how it works at all. This is dangerous because they are entirely dependant on the AI to make good decisions and to make any changes in the future.

Someone who practices engineering by researching, considering their options, planning and designing, and creating a specification, leaves nothing up to chance. When the prompt is detailed, the outcome is constrained to the engineer's intent. If they then review the work by seeing that it wrote what they had in mind, they know that it worked and they know that the system design matches their own design. They know how it works because they designed it and they can modify that design. They can and have read the code so they can modify it without the help of the AI.

If you know what code you want generated, reviewing it is easy - just look and see if it's what you expected. If you didn't think ahead about what the code would look like, reviewing is hard because you have to start by figuring out what the codebase even does.

This goes the same for working in small iterations rather than prompting am entire application into existence. We all know how difficult it is to review large changes and why we prefer small changes. Those same rules apply for iterations regardless of whether it was written by a person or an AI.

AI code generation can be helpful if the engineer continues acting as an engineer. It's only when someone who isn't an engineer or when an engineer abdicates their responsibilities to the AI that we end up with an unmaintainable mess. It's no different than amateurs writing scripts and spreadsheets without a full understanding of the implications of their implementation. Good software comes from good engineering, not just generating code; the code is merely the language by which we express our ideas.

But that was a large part of it. When it was difficult to write correct, well-structured code, that was a major determinant in who would get a job as a developer - ability to design and test came second. Now that generating code is automatic, it's the rest that becomes important. That works well for those of us who could do all of those things, but hurts those whose only ability was to generate code.

Maybe 30-40 years ago. For as long as I've been around the basic ability to write good code was secondary to a long list of other skills.

That's different than saying a lot of people *believed* writing code was the hardest/most important part.

Same here. I like bringing ideas to life; code is just a means to an end. I can now give detailed designs to an AI and let it write the hundreds of lines of code in just minutes, and with far fewer typos than I would make. It's still not perfect - I have to review it all - but if I give it a proper spec in generally creates exactly what I had in mind.