Azkar

I use the max plan, I don’t usually check the usage for a full build so I don’t know exact token usage.

Looking at my recent usage, it’s the second most after the feature orchestration itself. It will also depend on how many claims it has to verify and what I’m building. It’s the most valuable piece of glue that I’ve found when passing things between other focused agents.

My experience is with Claude, but I expect other frontier models would work just as well.

> I often wonder when coordinating the agents and reviewing their findings starts taking more time and effort than working with a single agent

I think this is a great question, and it probably needs to be re-evaluated every time models change. I added each of these to my workflow because I found that as my project grew in size and lines of code, single agents were missing large pieces of context and needed to be fed a lot of guidance. You can also determine how many/which type of agents to spawn based on the size/risk of the change. Ultimately it's probably a trade-off between speed/safety. For short term projects, a single agent is fine.

> I have a hard time understanding how that is being achieved. Are you finding yourself naturally gravitating toward that type of velocity and having to push back on it?

I can see it. I do have to push back on the urge to want to do more things in parallel. However, the more I use these agent workflows, the more I trust them, the more autonomy I give them. I have no problem passing a well written ticket to an agent and trusting it to build/test/merge/validate the change in prod.

I had claude define an agent for a "skeptic", the first few lines in the agent file are "You are a skeptic. Your job is to refuse to take claims on faith and instead verify them against ground truth. You are not a general code reviewer. You are not a stylist. You are not a cheerleader. You take a list of claims (explicit or implicit), and for each one, you find the evidence — or the absence of it — and report what you found."

It goes on to describe what counts as a claim, how to verify the claims, and how to respond. It responds to each claim with verified, unverified, or contradicted.

The skeptic agent has been the most high value thing I've added to the workflow.

This has been my experience (with downloaded skills), and currently my workflow is almost 100% skill driven.

Every feature I build uses a skill that does the following:

1. Read a ticket and get context on the task. The ticket was probably written by another agent after a conversation with myself about what is happening/needs to happen, etc.

2. Plan the task, asking for clarification where needed

3. Pressure test the plan, and validate the plans logic (subagents)

4. Implement

5. Runtime/local validation

6. Post PR, review it using applicable agents (database, security, code, prose...)

7. Fix PR based on feedback

I generally get excellent results out of this process, and I cannot imagine trying to orchestrate this without a skill. But I also can imagine my workflow isn't tuned to be super usable for anyone else.

> No, it is more accurate to say that leadership at Cloudflare does not know what they are doing nor have they known what to do for a good decade now.

I think we're starting to see that across the entire industry. Leadership is easy when times are good. The job has gotten very hard.

I read The Cuckoo's Egg only a few years ago (in my 30s) and it's an absolute delight. Easy to understand if you do any sort of linux administration, and really demonstrates how lax things were and how far we've come in terms of cyber security.

AWS Lambda supports shipping your Lambdas as containers now. Very nice experience.

Yep. I've found that the ticket or tech debt isn't important until it becomes on fire and must be fixed ASAP. It doesn't matter that the possibility for the bug to happen has existed for 2 years, the organization doesn't find the investment worth it until it's burning down the house.

about 40 and growing

Having dealt with all of these in production, I can tell you the strategies I've used to combat these things:

1. Solid code reviews. Anyone of our developers can halt a code review for any reason. We require 3 approvers on each review. Sensitive areas require reviews from people familiar in that area. We also have tooling that allows us to generate amounts of test data in dev that is similar to prod loads. This helps us catch a lot of time bombs.

2. Feature toggles to decouple deploy of code from release of code. This allows us to test our code in production before turning it on for customers. It also allows us to slowly rollout a feature and watch how the code behaves. This also gives us a kill switch to turn off the code if it is bad.

3. An incredibly robust testing pipeline. It takes about 50 minutes from commit to production deployment. We can also deploy previous containers very quickly for situations that require it.

This doesn't solve all of our problems. Some changes cannot go behind feature toggles (DB migrations, dependency upgrades, etc). But we do pay a lot of attention to design and rollout plans for database migration changes and such.

All of these things come at an extra cost to us, but it allows us to move quickly when we need to. But we're in a lot better place than we were when we were trying to do weekly releases. We have a good mix of team experience (sr vs jr) - and have a lot of discipline in our software engineering practices. We still have problems like I said, but these strategies have greatly improved our ability to deliver software.

> I've worked at a lot of places like this, and I'm continually surprised people enjoy it.

That's been my experience as well. When a manager says they try to "shield you from the bullshit" it's just a lack of transparency that leads me to making my own (often worse) assumptions.

I once read an account of someone that took Ibuprofen on an empty stomach and burned a hole in their stomach lining. Since then I always eat something first.

> Will the politicians still ignore the desires of its constituents vs special interests? No question.

It seems like none of this actually matters until we can solve that problem.

> You have to really provide valuable, quality content for organic SEO

This is the key. Google wants to make sure your readers are getting their questions answered. SEO is constantly changing, but high quality and valuable content will always be king.

> If you call a script that does a few seconds of processing, and keep calling it, yes it will take down the server...

aka, exploiting the script loading behavior...

> My network carrier already does some anti net neutral things that I like.

What happens when they start doing things you don't like?

> They have to do more than just accept the comments.

Or what?

There's no one enforcing rules in this administration.

Fantastic response.

~4 hours from report to release.

It's hard to move fast and have a well engineered product.

You should check out Rocket League.

So what's the big picture here? We've suspected for years that football leads to brain trauma. Does that mean the NFL should shut down? Should they continue to operate as normal?

There have been efforts recently to make the game safer for players, but the amount of concussions and injuries seen every season don't seem to be decreasing.

Can you make the game "more safe" without drastically changing the game? Any game played at this high of a speed, with this strong of players is going to have some inherent danger to it.

Do we just need to make the effects more widely known and understood by the players, maybe treat football like smoking with warnings printed on the outside of helmets? Anything less than that and you run the risk of not making your point.

Should I feel bad as a fan for watching football? Is it any worse than buying clothing made by child labor from a third world country?

Yeah, let's not feel bad for the airlines. They do it to themselves.

It sounds like he's doing quality work, really. There's no secret. He claims to have a GREAT copy writer for his niche and provides them with the exact info they are looking at google for. Do that for a few hundred well written articles and any site will rank well too.

But a google algorithm change could definitely crush his income.

Yeah... this seems like a really fast way to lose customer trust.

I'd love to take you up on this offer as well... sdm350 at gmail

Solutions usually come from people who see in the problem only an interesting puzzle, and whose qualifications would never satisfy a select committee. -- John Gall in Systemantics[1]

A very short read, and quite interesting. It touches on a lot of the same points already made in this thread (people will game metrics, etc). The biggest argument that the book makes that is trying to set up a system to accomplish something will cause the system to do everything but accomplish its goal, which leads to the above quote. You can't set up a system to achieve a goal, only set up an environment that allows the goal to be achieved.

[1] https://en.wikipedia.org/wiki/Systemantics

There are tradeoffs to all software.

I use lastpass with a yubikey for 2fa and I feel safe enough. I briefly looked at other password managers when I was evaluating lastpass, but convenience won out for me. I haven't looked at moving out of lastpass, but 3 years ago no other password manager came close to the mobile and platform support that lastpass had.

I considered keeping my passwordDB local, but the inconvenience of needing it and not having it wasn't it worth it to me. Do I know I'm making a tradeoff? Yes.

I also have a nasty habit of setting things up on a local server and then never updating it. Instead I decided that lastpass was worth the $12/year so I wouldn't have to manage anything locally.

So while lastpass may not be perfect security, I'm a lot better off than I was three years ago when I used the same few passwords everywhere.

It also helps me share passwords with my wife, so that's nice.