Posted by poisonfountain 1 day ago
:-(
I love that Codex added "Steer" to the chat, because I fucking pay attention to the conversation traces on coding agents and I was tired of the PANIC ESC - "No, that's not what you should do! We use a visitor to calculate all that stuff, I just need you to implement another visit method for this new Stuff according to the rules".
Nothing says you shouldn't write any code, in fact, I think that starting from a n interface and a few clients is superior to simply describing things only in natural language. Lots of refactors like extracting method, extracting interface, renaming symbol are way faster, cheaper (no tokens) and less error prone using the IDE.
When I am not sure about the concrete design to implement something, I talk to the coding agent, we discuss types, i suggest patterns, I wrote a small stub here and there, maybe a couple unit tests, but I like to activelly engage with the coding agent as if I was pair programming.
Yeah, I am not a fan of fire and forget, I see no point in being able to control agents remotelly, but nobody is complaining I am not fast enough. It is perfectly possible to have the huge productivity gains coding agents give you without entering vegetative programmer mode. You just need to engage yourself in the process.
You can describe the different categories of something, or you can go ahead and create an enum in rust, you can create a pydantic validator, a few tests here and there. The agent now has something more concrete than a natural language description, it has the compiler to check his code, it has the unit test. The flow becomes faster.
You can mention in your prompt that the agent should use AWS SDK v2 in your Go service, or you can go ahead and add the imports and the initialization somewhere in your code, the second option is a far stronger nudge towards the right direction.
The time you used to waste trying to shoehorn some stack overflow answer to your problem, now you can use to actually read the documentation of whatever you're trying to use. Go ahead, read it fully, you now have time to understand it deeply. The grunt work, the toil will be taken care of by the agent in a few minutes when you're finally feel yourself ready to move to implementation, because now you have the deep knowledge to take the best possible decisions.
There are plenty of places for you to apply your knowledge: the agent may write a correct function, but then this function does a remote HTTP call in the context of a database transaction, so, what happens when the remote http endpoint has a spike on latency? And what if the tables involved on this transaction are a hotspot in your application? You can't add all those small details in your context all the time, you can't add all single corner case and potential pitfall to your AGENTS.md.
Of course, you have to up your game. If all you ever did was completing JIRA tickets without thinking much about it, yes, there's no much you can add to the process beyond what your coding agent can do. But this is a choice.
We can either create a humongous era of slop and technical debt with coding agents, or we can use its hability to free ourselves from toil so we can finally improve our code in correctness, performance, efficiency, efficacy, security and compliance all the while keeping the business happy.
We can either use LLMs to have tens, hundreds, thousands of THERAC-25, or we can use them to liberate our time so we can do the deep work that ensures that you can't possibly deploy a THERAC-25 in production.
> I'm still employed and I see myself employed for a foreseeable future. But I don't know what to think about the long-term ... Maybe I should consider transforming my woodworking hobby into a profession.
This one is notable for having all the clues pointing to why that's not the end-state this is headed toward, and yet... still not quite see it.
> I have no domain expertise that another Sr. engineer steering an LLM cannot match.
It's clear he's developed a significant competence in "steering an LLM" but the depth and value of that aren't apparent yet. After ~70 years, software development is now in the early stages of its first tectonic disruption. In the moment, these kinds of tech disruptions mostly appear to be displacing jobs but, historically, we understand the displacement is one part of a larger shift that's vertically compressing roles, functions and labor value. One steam shovel doesn't just displace dozens of pick-axe swinging diggers, it changes the roles, functions and competencies required across the entire supervision and management stack of "make tunnel through mountain" from the crew bosses and site managers to the tunnel engineers and business owners.
The author seems to be successfully navigating this shift but is still mid-disruption, so he and his management aren't yet able to see all the new competencies required or appreciate their value because it's all so new and still evolving. The rapid shock of agentic coding LLMs is especially disorienting because it's the first dramatic disruption in the field.
> review the code and steer the robot.
Historically, it's not surprising those few words are bearing so much weight and unappreciated value. Steam power was a similar shock to every field which relied on earth-moving and shaping. The big machines were quickly deployed, but it took quite a while for all the disruptions to both new and existing roles, functions and necessary competencies to be understood and appropriately valued. I imagine some top pick-axe swingers who'd graduated to being crew bosses and site foremen ended up driving or directing early steam shovels. In the first months they probably had little appreciation for the tremendous amounts of tacit new knowledge and practical expertise they accrued while keeping the steel beasts working. They were too busy being both amazed at the sheer power and frustrated by the constant scalding burns, tip-overs, blown boilers, landslides (too much weight, too little support) and cave-ins (dug too much tunnel, too fast with too little scaffolding), etc.
A big difference in the analogy is the first 100,000 steam shovels weren't sold at ~1/10th their actual cost and simultaneously delivered to job sites worldwide in six months. Software engineering is also unlike earth-moving and tunnel digging, in that the full costs and consequences aren't as visible or immediate as cave-ins and avalanches. The prices of 'steel beasts' are already going vertical with no end in sight and, over the next 18 months, I suspect "management" is about to gain a more viscerally accurate appreciation of the catastrophic costs of digging 'too much tunnel, too fast' absent the close supervision of highly skilled experts in directing all that newfound power constructively and not destructively. Between the skyrocketing full cost of operation and the consequences of poorly managed, non-expert execution - we'll start to see the broad outlines of the new equilibrium take shape.
In the steam era it over a decade for the ecosystem to understand how to even draw a new org chart accurately, label the boxes and appropriately value proven competency where it mattered. The faster the disruption, the longer it can take for all the pieces to rebalance and stabilize around a new equilibrium. Today, the author doesn't know all that he already knows and doesn't yet have the visibility to see how the new domain competencies he's rapidly accruing are creating a different kind of role that could be even higher value.
Yeah. There is no future in IT any more, let's be real. Enough CEOs have drunk so much AI kool-aid that they'll lay off so many people it will become outright impossible to get re-hired again when the incompetent CEOs have gotten fired - too much competition.
The only industry that's going to give reliable employment in the future is the trades, especially the regulated/licensed ones. Gas, water, electricity, structural engineers - basically everything where there is actual human lives on the line when things go south.
It’s not useless, at least not yet. And the fact that you recognize this puts you way ahead of the typical HN user constantly crying about how AI could never
What’s going to make you a good AI-augmented engineer is going to be treating AI like a good partner
Not like a genius, not like an idiot - these are extremes where all the memes on LinkedIn are generated
Like any partnership you will see it comes with bad ideas and good ideas - that it will challenge your own ideas and be sometimes wrong and sometimes right
Approaching it this way, I think my learnings only accelerated - the conversation is of much higher value because it’s a fast back and forth where I can take a moment to learn on those occasions where its ideas beat mine
You are feeling a little insecure, paranoid is not the word, and that’s a good thing
Tackle the problem for what it is: I have this sidekick now that can help me bang shit out in a fraction of the time it used to
Use the the brain that got you here to figure that out - don’t waste your time on these debating whether ai is good or not or listening to stories about how it’s stupid because one time it suggested something that wrong
You’re going to be fine, put AI to work for you
Ask me again in a few months but for now you’re fine
For one: LLMs make a lot of mistakes. We all see that when they hallucinate search results and what not. But, possibly even more important than that, you ultimately become dependent on some big company via LLMs. Perhaps that trade-off is worth it for some companies, but I personally don't want to become dependent on these companies. I actually consider it a hostile attack from the USA, and under Trump this is even more obvious.
Another thing that sucks by LLMs is documentation. They generate a lot of crap that is useless. So that's another area where humans could be better.
Admittedly a lot of vibe-coded AI slop is also useful in some ways, but it has started to make me rather angry in general - youtube already spoiled me here. I no longer want to see ANY AI videos at all whatsoever. It just wastes my time. I am not here to empower skynet version 20.2.