Setting aside the "capability" of the tools, I knew it was the wrong direction after a couple months or so in. I specifically remember during a large feature implementation running out of tokens for my 5 hour window or whatever, and I just couldn't continue on my own. Mostly due to laziness (I'll just wait till tomorrow when my limit resets!), but I also picked up on my first big whiff of skill rot / atrophy brewing, and that made feel uncomfortable.

I just don't see this fully agentic approach going well long term. Talk about the ultimate dependency!! If the lights are "turned off" for whatever reason - outages, cost increases, or the agentic velocity finally reaches a complexity tipping point and you've lost control and understanding of your system to the point the agents are making things worse, whatever it is - do you really expect to be able to turn back the clock and step in to code at the productivity level and output you used to when you actually... wrote code?

Facts. For me the bigger the gap between what i saw in my head and the speed with which my fingers could physically make it a reality the more stress i would feel and some marathon coding sessions would end w my back all messed up just from the tension

For me, this means the checks have to be more than just "I looked at it". There are two things that happen before I ever see it: first, as others have mentioned, I have a model from a different family review it with well-defined criteria. Same-family reviewers share bias, so it must be a different one. Second, I have a core set of deterministic gates (like lint, but also unit tests) that must run. In either case, failures go back to the coding agent.

And only then do I bother. But I really don't read everything. If it is bog-standard CRUD operations, the agents are pretty good at that, especially if they are using mature packages. I focus on critical things, like how it enforces permissions.

This works well for me, though it leaves one major issue untouched: whether this is worth building. The agents tend to be a bit overeager, so I have to do a lot of work up front to make sure the output will add value. The gates can only check the artifact, not my intent.

Software engineering is dead, long live software engineering!

First, it takes me ages to describe the task properly. All these clear success criteria, well, instead of writing code from a clear spec in my head, I’m writing tons of prose, and trying to make it unambiguous. I’m programming in English++.

But then, one time in 5, it produces something that kinda works. Maybe not perfect but good enough. Two times out of 5 it kind of sort of looks alright, but actually ignores 80% of the spec, or pays it minimal lip service in the comments.

And sometimes, maybe a bit less than 2/5, it just completely diverges into total shit. Starts writing scripts that load the ast of the main script and pickle it then serialise to base64 for no good reason. Encode some stuff in strings then check ord(string[i]) repeatedly for string comparison. Eventually runs out of context and develops the LLM equivalent of severe dementia.

I truly cannot reconcile my experience with people who seem to say “hey computer write this” and it’s a good use of their time.

Maisem Ali writes about how they have not stopped engineering despite handing production of code over to AI. I think that's an interesting perspective for a few reasons, but most of all, I'm not sure I agree.

First, we see a prime example of how that can blow up. "botd died this month. It crumbled under its own weight." It's hard to imagine how an agent harness (or is it an overlay on top of other harnesses?) could crumble under its own weight from sheer technical complexity. What makes a tool like this "crumble"? If properly architected, it seems that any outside change could be adaptable. Failing tests could be fixed.

This AI coding evolution has given us the ability to spin up prototypes we don't understand the inner workings of, but I believe for anything of value (and, I would argue, botd appeared to have value to Maisem) we should at the very least understand and influence the architecture and engineering of what we're building. If Maisem had done that for botd, it would not and _could not_ have "crumbled under its own weight". Whatever outside influence required change within botd would have been manageable.

Second, the off-loading of the production of this article indicates to me a lack of respect (with no offence to Maisem, because this is what much of the industry is doing today) for the value in thinking through the writing process. There's a lot that I've learned personally about software I worked on that only came to me through trying to write explainers. Taking a step back from the software we build and looking at it from a birds-eye view, to share how it is constructed or how to use it, helps develop our understanding.

Maisem's article is already very good, and I hope that is demonstrative of their own writing! I would read more! But I want to read words written by a person for other people. AI can help edit, it can help us build ideas, but in code and in our written word, AI should not be _the author_.

I'm predicting a Docker for AI Coding. There really is a ton of stuff you need to set up to do AI coding/vibe coding in a way that's safe, has good results, and is fast. You don't just need a dev environment, you need a whole SDLC; codified good engineering decisions, test framework, credential management, an interactive UI and notifications, guardrails, a "waterfall" of progressive design/build/test, context management, and much more. It's too much for people to put together themselves without tons of time and experimentation. Same as containers, which is why Docker came about: to let an end user do complex things in an easy way.

AI coding is like a self-driving car. Making the car move is easy; making it get you to the destination you want safely is very hard.

After reading this blog post for me, Fable-1337-B4242 asked me if I also wanted to create a load-bearing plain text website like exe.dev using agentic forces.

That all reads to me like: The key here is: "Burn tokens as money in a bonfire, pray you typed in the right magic spell (prompt) and the ingredients (context) in the potion were right, toss away the failed elixir of life".

Instead of writing code and refactoring yourself and gaining an understanding, you're hoping that a slot machine will get luckily get the statistics right to put up code that you already need to read again.

> It’s the same loop that taught me to code, moved up a level: write, run, fail, fix. I used to iterate on code. Now I iterate on prompts, designs, whole features. A rewrite that used to cost a week costs a conversation.

And also costs you skills atrophy and however much tokens will be. Not to mention the negative externalities of using LLMs (massive increase of fraud, of disinformation, of rocketing prices in memory and in turn all electronics, massive use of energy that consumers have to also then pay extra for, environmental and noise cost of using on-site turbines, local destruction of water resources for the local community).

AI agents are just software, so the only way to understand them is trial and error?

Every few months it feels like I have moved further up the chain. Now I don’t even look at a PR until it’s been coded and gone through at least 2 AI reviews (always different families). Code is truly cheap. I can have the pipeline produce an entire feature as a thought experiment just to see if the shape is the right fit for the codebase. People like to throw the slop term around a lot. It feels like the opposite of slop through. I can have things written and rewritten as many times as it takes until I’m happy with them.

The weakness I see in this is there at the end. The agents never want to throw things away. They just want to keep adding and adding. I think this is my real value in the chain. That intuition built up over years that says this isn’t right yet or that little tingle in your brain that you’ve laid a landline that you are going to step on in 6 months.

> Instead of waiting, I spun up another agent to do something else. Then I did it again.

> I wasn’t intentionally building a parallel system. I was just filling the time between tasks. I have ADHD. I got distracted.

I probably have ADD or ADHD and this feels "great" at first b/c you can just jump back and forth between 2-4 agents as they need input from you.

But I noticed:

1. I was EXHAUSTED at the end of the day

2. A lot of what each agent was doing I could do faster myself. Yes, if I do 10 units of work and 4 agents do 3 units then it's faster. That being said, sometimes all of the agents pick the dumb/slow path and now it's 4 agents times -2 units

> Having other agents review the code worked surprisingly well. They occasionally caught real bugs, and it was cheap enough to run several reviews. But I couldn’t merge something just because the agents approved it. I still had to understand the change. I was still responsible for the code that got merged.

My personal opinion is that LLMs have:

- 5x increase in triaging/debugging b/c they can read code WAY faster and make connections really quickly

- 2-3x writing code if you ALREADY have great, rock solid unit tests etc

- -1x to 1.5x improvement in writing greenfield code where you have no tests

That last one is b/c you are never 100% sure that the test is doing what you expected or the LLM is "hacking the test" (unless you REALLY read the code).

I think this disparity in performance across different sub-domains of being a SWE/SRE is why you get so many different opinions on LLMs

I met a few architects/team leaders who wouldn't write almost any code and just technically oversaw things before LLMs got popular, obviously they were very experiencied.

What you have to ask yourself is whether you could oversee a swarm of bots(or people) if you didn't have any coding experience in the first place.

A lot of HN users seem to be, in my opinion, too dismissive about the complexity of creating software. It's true that we don't have to develop in assembly anymore to be a good developer and with time the general level of the entry abstractions that we deal with rises, but, in my opinion once again, it will never change the fact that you need a high number of hours of exposure to something in order to be truly competent to a professional level.

that's the moment I thought... is this all an advertisement?

It seems that all this knowledge would be useless with a model update...Good for the AI companies though. More tokens as users like this come upto speed with the new models, which they now are totally dependent on...

Because, if you didn't like writing code, and is now used to agents writing code, good luck going back to writing code by hand...

To me it just feels like you want to be a manager not an engineer

This is like if a plumber said. I no longer do any construction, I just tell people what to do. Then you probably aren't a builder anymore, you are a foreman or a project manager.

I think your job as an engineer is to know the codebase and how it was engineered

Can we stop posting obviously slop articles? If you can't make the effort to write the article, I'm not going to make the effort to read it.

Edit: I recall reading somewhere that John Carmack doesn't care about which editor he uses because typing was never the bottleneck. Admittedly, he worked on some really difficult problems.

1. https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

The research, the understanding, the planning, the design, all of it's iterations, the testing, all of it's iterations, debugging etc.

'I see the code and need to get it down' is a key thing obviously but a smaller part.

With better abstractions, we'll be putting 'architectural ideas' in our head, instead of algorithmic.

Or, consider what information is driving your extremely detailed instructions and give it the raw source if you can. Meeting transcripts, messy notes on some adhoc conversation, etc.

The more you try to micromanage it, the more impossible to work with it it is.

Of course not every situation calls for just giving it high level requirements. But not every situation calls for trying to define how everything is done yourself either.

These issues are usually in really tedious places that I didn't bother to describe what to do to the agent

I'm pretty sure that's the dream goal of any plumber. No one "plumbs for fun". No one wants to truly do the actual thing, they want the money that allows them to do whatever they want. It's just that doing the actual thing is the only way you can get the money at first. And being good at doing the actual thing and enjoying doing the actual thing makes doing the actual thing bareable or even fun while reaching your actual goal (the money). As soon as you can free yourself from that you will.

I like to make computers do the things I want. Since I was a kid, the satisfaction from programming or any sort of "computer engineering" (using the word engineering VERY loosely here) is in making something specific happen.

Sometimes, that means understanding the correct data structure to use, picking the right algorithm, and other computer science-y things.

Other times, and more often (for me), it means death by a thousand papercuts in managing third party dependencies, boilerplate, and other tedium and minutia.

I'm not someone who is "proud" of barely coding anymore, and I'm not entirely sure how I feel about the "structural soundness" of using LLMs this way (most of my coding is personal/hobbyist work), but I can confidently say that I don't really code just because I love coding, at least necessarily. I like making stuff.

A manager has access to a larger, sloppier, and more powerful API than an engineer.