I would say they're great until they aren't. Which means at some point in a session or in a long-lived-project they will resist very hard being steered like it would be done by another developer, product manager, a designer, or just the market in general.
Most people don't find this to happen because the size of projects and the granularity of the expectations are wildly different.
I found that agents help, even if you don't parallelize. Having one agent control another and verify its results against rules you set has worked well for me because the controlling agent has no incentive to cut corners, and the implementor might, but it is being controlled.
My usage might be much simpler than what you do, but it went from "but I gave a list of things to do, you only did 5 of them" - "okay, here are the other 7, oh btw, I skipped the verification rule because nobody has time for that" to good compliance, the orchestrator starts the sub agents, tells them exactly one thing to do, and makes sure they've done it afterwards.
makes sense on planning as well, I think. spend your tokens on the best model to explore the problem and design the solution, but the implementation and testing/verification cycles don't need the strongest model you can get.
I only get anything useful when I force extremely strict standards and opinions so that it is impossible to deviate from what I want. That only really works in some languages and some programming styles. Whenever I try to do something less constrained there is some sort of patina of stupid that can't be polished away mechanically.
I am mostly worried about the current AI use in management. I’ve met a few with ”AI hubris” making poor managerial decisions that stem from their poor usage of ChatGPT (not understanding the importance of context, model sycophancy, etc).
Some people that are immune to listen to people with more experience will continue to be ”junior” forever. They may eventually not have the title junior, but they really are.
There are fundamental differences. Many people expect a positive gradient of quality from AI overhaul of projects. For translating back and forth, it is obvious from the outset that there is a negative gradient of quality (the Chinese whispers game).
200 times?? No, I don't think anybody expected that to produce something good. It's just a other attention grabbing, "I did a thing a ridiculous amount of times!" stunt.
You're assuming the author did this only for audience engagement(dozens, nay, scores of blog hits!), and not to gratify their own intellectual curiosity? Sometimes you just want to see what happens.
My tip is: don’t use SDK:s for agents. Use a while loop and craft your own JSON, handle context size and handle faults yourself. You will in practice need this level of control if you are not doing something trivial.
Well, considering git is only version control, and github does much more... pull requests, social interaction, workers/workflows, ci/cd etc. It's kind of a big deal.
Unless you have some sort of decentralized method of doing CI/CD and pull requests I'm unaware of?
Reminds me of C#.. IDisposible and IAsyncDisposible in C# helps a lot to write good mechanisms for things that should actually be abstracted in a nice way (such as locks handling, queue mechanisms, temporary scopes for impersonation, etc).
That's because the author of the proposal is from Microsoft and has repeatedly shot down counter-suggestions that made the syntax look different from C#.
It's basically lifted from C#'s, the original proposal makes no secret of it and cites all of Python's context managers, Java's try with resources, C#'s using statements, and C#'s using declarations. And `using` being the keyword and `dispose` the hook method is a pretty big hint.
trivial doesn't mean the AI will get it right. A trivial request can be to move an elephant into a fridge. Simple concept right?
Except AI will probably destroy both the elephant and the fridge and order 20 more fridge of all sizes and elephants for testing in the mean time (if you're on MCP). Before asking you that if you mean an cold storage facility, or if it is actually a good idea in the first place
Building even a small a web frontend involves a huge number of design decisions, and doing it well requires a detailed understanding of the user and their use-cases, while internationalisation is a relatively mechanical task.
And that’s kind of decision making is what’s important. More often than not, you ask someone to explain their decision making in building a feature, and what you get is “I don’t know really”. And the truth is that they have externalized their thinking.
They’re inherently very different activities. Refactoring a file assumes you’ve made a ton of choices already and are just following a pattern (something LLMs are actually great at). Building a front-end from nothing requires a lot of thought, and rather than ask questions the LLM will just give you some naive version of what you asked for, disregarding all of those tough choices.
Disagree. There is almost no decision making in converting to use i18n APIs that already have example use cases elsewhere. Building a frontend involves many decisions, such as picking a language, build system, dependencies, etc. I’m sure the LLM would finish the task, but it could make many suboptimal decisions along the way. In my experience it also does make very different decisions from what I would have made.
The AI will pick the most common technologies used for this purpose, which is both "good enough" and also what people generally do at scale (for this exact reason).
This was the promise of no-code. ”All apps are crud anyway”, ”just build for common use cases” etc. This didn’t turn out to be true as often as predicted. If averaging people’s previous decisions was truly a fruitful way, we’d have seen much stronger results of that before AI.
On the contrary, it turned out to be exactly as common as predicted, which is why you see so many people going "this AI assistant thing makes me 100% more productive". It's precisely those tasks. And they are handled in precisely this way by humans, too - throw whatever the popular stack of the day is at them. And sure, it results in inefficiencies and crappy code, but that code is "good enough" wrt what the customer wants it to do.
