The agent basically is living inside your running app with access to databases, endpoints etc. It's awesome.

1. https://tidewave.ai/

In this case, “Iran war” is a bit misleading because the conflict is largely a missile and proxy confrontation affecting several territories (Iran, Israel, and parts of the Gulf), not just one battlefield.

Personally, I find it clearer to name conflicts after the primary actors involved. For example:

Russia–Ukraine war U.S. & Israel–Iran war

That makes the participants explicit instead of implicitly framing the war around a single country or location.

Just observing, not saying it's a good or bad linguistic practice

Another way to name wars, when they aren't happening to you, is based on where they happen. The war is happening in and around Iran. It's very unlikely that Iran will manage to bring the war to America. You could also call it the Gulf of Persia war.

You can also name them propagandistically, as in the "2023 Israel-Hamas war". Thankfully this hasn't happened in this case.

I wonder what they call it in Iran?

I also spend most of my time reviewing the spec to make sure the design is right. Once I'm done, the coding agent can take 10 minutes or 30 minutes. I'm not really in that much of a rush.

Add to that I have worked on many projects that take more than 20 minutes to fully build and run tests... unfortunately. And I would consider that part of the job of implementing a feature, and to reduce cycles I have to take.

After the "green" signal I will manually review or send off some secondary reviews in other models. Is it wasteful? Probably. But its pretty damn fun (as long as I ignore the elephant in the room.)

The other day, I wrote a claude skill to pull logs for failing tests on a PR from CI as a CSV for feeding back into claude for troubleshooting. It helped with some debugging but was very fraught and needed human guidance to avoid going in strange directions. I could see this "fix the tests" workflow instrumented as overnight churn loops that are forbidden from modifying test files that run and have engineers review in the morning if more tests pass.

Maybe agentic TDD is the future. I have a bit of a nightmare vision of SWEs becoming more like QA in the future, but with much more automation. More engineering positions may become adversarial QA for LLM output. Figure out how to break LLM output before it goes to prod. Prove the vibe coded apps don't scale.

In the exercise I described above, I was just prompt churning between meetings (having claude record its work and feeding it to the next prompt, pulling test logs in between attempts), without much time to analyze, while another engineer on my team was analyzing and actually manually troubleshooting the vibe coded junk I was pushing up, but we fixed over 100 failing integration tests in a week for a major refactor using claude plus some human(s) in the loop. I do believe it got things done faster than we would have finished without AI. I do think the quality is slightly lower than would have been if we'd had 4 weeks without meetings to build the thing, but the tests do now pass.

I’ve gotten some success iterating on the one-shot prompt until it’s less work to productionize the newest artifact than to start over, and it does have some learning benefits to iterate like this. I’m not sure if it’s any faster than just focusing on the problem directly though.

I still think that we, programmers, having to pay money in order to write code is a travesti. And I'm not talking about paying the license for the odd text editor or even for an operating system, I'm talking about day-to-day operations. I'm surprised that there isn't a bigger push-back against this idea.

Fortunately, there was enough work to be done so productivity increases didn't decrease my billable hours. Even if it did, I still would have done it. If it helps me help others, then it's good for my reputation. Thats hard to put a price on, but absolutely worth what I paid in this case.

It's usually not about the price, but more about the fact that a few megacorps and countries "own" the ability to work this way. This leads to some very real risks that I'm pretty sure will materialize at some point in time, including but not limited to:

- Geopolitical pressure - if some ass-hat of a president hypothetically were to decide "nuh uh - we don't like Spain, they're not being nice to us!", they could forbid AI companies to deliver their services to that specific country.

- Price hikes - if you can deliver "$100 worth of value" per hour, but "$1000 worth of value" per hour with the help of AI, then provider companies could still charge up to $899 per hour of usage and it'd still make "business sense" for you to use them since you're still creating more value with them than without them.

- Reduction in quality - I believe people who were senior developers _before_ starting to use AI assisted coding are still usually capable of producing high quality output. However every single person I know who "started coding" with tools like Claude Code produce horrible horrible software, esp. from a security p.o.v. Most of them just build "internal tools" for themselves, and I highly encourage that. However others have pursued developing and selling more ambitious software...just to get bitten by the fact that it's much more to software development than getting semi-correct output from an AI agent.

- A massive workload on some open source projects. We've all heard about projects closing down their bug bounty programs, declining AI generated PRs etc.

- The loss of the joy - some people enjoy it, some people don't.

We're definitely still in the early days of AI assisted / AI driven coding, and no one really knows how it'll develop...but don't mistake the bubble that is HN for universal positivity and acclaim of AI in the coding space :).

People who enjoy the process of completing the task?

Initially there is perhaps a mitigating advantage of briefly impressing ourselves or others with output, but that will quickly fade into the new normal.

Net result: employee paying significant money to produce more, but capturing none of that value.

No. But it is noteworthy. A lot of what one previously needed a SWE to do can now be brute forced well enough with AI. (Granted, everything SWEs complained about being tedious.)

From the customer’s perspective, waiting for buggy code tomorrow from San Francisco, buggy code tonight from India or buggy code from an AI at 4AM aren’t super different for maybe two thirds of use cases.

Only if you ignore everything they generate. Look at all the comments saying that the agent hallucinates a result, generates always-passing tests, etc. Those are absolutely true observations -- and don't touch on the fact that tests can pass, the red/green approach can give thumbs up and rocket emojis all day long, and the code can still be shitty, brittle and riddled with security and performance flaws. And so now we have people building elaborate castles in the sky to try to catch those problems. Except that the things doing the catching are themselves prone to hallucination. And around we go.

So because a portion of (IMO always bad, but previously unrecognized as bad) coders think that these random text generators are trustworthy enough to run unsupervised, we've moved all of this chaotic energy up a level. There's more output, certainly, but it all feels like we've replaced actual intelligent thought with an army of monkeys making Rube Goldberg machines at scale. It's going to backfire.

I don't mean 'Oh I finally have the energy to do that side project that I never could'.

Afterall, the trade-offs have to be worth something... right? Where's the 1-person billion dollar firms at That Mr Altman spoke about?

The way I think of it is code has always been an intermediary step between a vision and an object of value. So is there an increase in this activity that yields the trade-offs to be a net benefit?

Every restaurant in my small town has their menu on the website in a normal way. Apparently someone figured out you can take a picture of a paper menu and have AI code it into HTML.

So does the code produced by any bad engineer.

So either we’re finally admitting that all of that leetcode screening and engineer quality gating was a farce, or it wasn’t, and you’re wrong.

I think the answer is in the middle, but the pendulum has swung too far in the “doesn’t matter” direction.

We’re admitting a bit of both. Offshoring just became more instantaneous, secure and efficient. There will still be folks who overplay their hand.

Macroeconomically speaking, I don’t see why we need more software engineers in the future than we have today, and that’s probably a conservative estimate.

Why? Is the argument that there’s a finite amount of software that the world needs, and therefore we will more quickly reach that finite amount?

Seems more likely to me that if LLMs are a force multiplier for software then more software engineers will exist. Or, instead of “software engineers”, call them “people who create software” (even with the assistance of LLMs).

Or maybe the argument is that you need to be a super genius 100x engineer in order to manipulate 17 collaborative and competitive agents in order to reach your maximum potential, and then you’ll take everyone’s jobs?

Idk just seems like wild speculation that isn’t even worth me arguing against. Too late now that I’ve already written it out I guess.

I think this is my hypothesis. A lot more people with a lot less training will create vastly more software. As a consequence, the trade sort of dissolves at the edges as something that pays a premium. Instead, other competencies become the differentiators.

I've never met those people. I've met a LOT of PM who tried. I've met a LOT of entrepreneur who also tried. They never cared, nor even understand, code. They only cared about "value" (and they are not necessarily wrong about it) so now they can "produce" something that does what need until it doesn't. When that's the case then they inexorably go back to someone else (might be a SWE, ironically enough, but might also be someone else like them they shift responsibility to, for money).

Brute force works until you have to backtrack, then it becomes prohibitively expensive until one has to actually grok the problem landscape. It's amazing for toy projects though, maybe.

1. The restaurant isn't lacing your food with cocaine

2. The author is incentivizing reading, which is generally a good thing

You are right, it is our job to control our information diet but when the ability to control is diminished through the consumption, then we have a problem which doesn't fit into the model of "get your shit together".

There's also a social responsibility you inherit when you start selling products that have harmful side-effects. Auto manufacturers have to comply with emission testing, drug makers have to prove efficacy, air conditioning manufacturers have to adhere to air quality standards etc. What do social media companies have to do? Very little if anything, and that's the problem. We've yet to find a counter-balance that works and protects the consumer, so we're in this era where we're trying to find out what we can do, but the landscape is changing so fast that we're trying to hit a moving target.

Cocaine creates a much larger chemical change in the brain and can kill you in high doses so it’s not really comparable.

> 2. The author is incentivizing reading, which is generally a good thing

Says who? Why is reading inherently a good thing?

And all of those things are regulated because they have what most consider to be objectively bad effects on the body (with metrics based on cellular harm).

Product and design were always the bottleneck. Engineering speed was never the issue, it was the politics and indecision in product that always slowed engineering teams down. I can't count how many prep meetings product had before they presented to their boss what the new font and color looks like. They basically had a team of PMs just running around creating busy work and making decision based on pure whim and personal feeling, without actually looking at any data. And God forbid they ever talk to customers. Ew, who cares about what they have to say.

Engineers like to claim everyone else is their problem, when in fact, it's often the case that engineers are their own problem.

Bottlenecks happen everywhere.

Sometimes there’s valid reasons for addressing technical debt and reworking things to be better in the future… and other times people are just rewriting working code because reasons™.

Encountering the latter can be quite demotivating, especially when it turns to nitpicking over small stuff or keeping releases back for no good reason. Personally, I try to lean away from that and more into the “if it works, it works” camp (as long as you don’t ignore referential integrity and don’t mess up foundational logic).

Depends. It definitely can be. When you get those people who want to spend weeks going back and forth over whether the button should be red or slightly darker red, as if they can somehow figure out the right answer from gut feeling alone, not realizing that in that time they could have tried both and learned from it, all while delivering other things of value on top, engineering has no hope of becoming the bottleneck.

- Cleaner code - Easily 5x speed minimum - Better docs, designs - Focus more on the product than than the mechanics - More time for family