Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beyond agentic coding

haskellforall.com

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Beyond agentic coding

#81

Post by Gabriel439 »

brightstep wrote: post #47

> A tool is not meant to be the object of our attention; rather the tool should reveal the true object of our attention (the thing the tool acts upon), rather than obscuring it I think this is true of AI agents. What is the object of our engineering attention? Applications, features, defect resolution. Not code.

Author here: yeah, this is a good point and something I think about even outside the context of agentic coding.

I've also tinkered with this idea myself in the context of prompt engineering with my Grace Browser project (https://trygrace.dev/), which converts code to an equivalent dynamic web form live within your browser.

I do think it's useful to remember that code is not the end goal and is itself just another mediated interface to the actual goal: the product your building. However, I think even if you cut code out of the picture the chat interface is still not necessarily the right interface for building a product. A great example of how to build a non-chat interface to product building (predating the AI boom) is Bret Victor's Inventing on Principle talk (https://www.youtube.com/watch?v=PUv66718DII) and there might be ways we can refresh the ideas in that talk for the AI era (although I still don't have any specific thoughts along those lines yet).

Re: Beyond agentic coding

#85

Post by sourabhrakhya »

resize2996 wrote: post #65
rubenflamshep wrote: post #56

Earlier quoted context omitted.

> That said, the main issue I find with agentic is my mental model getting desynchronized. No matter how fast the models get, it takes a fixed amount of time for me to catch up and understand what they've done. This is why I'm so skeptical of anyone running 6+ Claude sessions at a time. I've gotten to 5 but really that was across 3 sessions with 2 standing by just to commit stuff. And even with just 3 sessions I cons…

Warning: I was in two different project experimenting with similar forms of db access at the same time. don't do that.

same

Re: Beyond agentic coding

#86

Post by brightstep »

Gabriel439 wrote: post #81
brightstep wrote: post #47

> A tool is not meant to be the object of our attention; rather the tool should reveal the true object of our attention (the thing the tool acts upon), rather than obscuring it I think this is true of AI agents. What is the object of our engineering attention? Applications, features, defect resolution. Not code.

Author here: yeah, this is a good point and something I think about even outside the context of agentic coding. I've also tinkered with this idea myself in the context of prompt engineering with my Grace Browser project ( https://trygrace.dev/ ), which converts code to an equivalent dynamic web form live within your browser. I do think it's useful to remember that code is not the end goal and is itself just another m…

Totally agree about the chat interface. I like to say it’s “infinitely powerful and infinitely confusing.” A dangerous combination. And, arguing with myself, I think it’s fair to say the code is AN object of our attention, if not THE object. A common metaphor being applied to agentic coding is the invention of power tools. If AI is the drill, and the goal is a house, then the code is the framing.

Re: Beyond agentic coding

#87

Post by bitwize »

BitsAndObjects wrote: post #42
adhamsalama wrote: post #16

Earlier quoted context omitted.

We don't solve LeetCode for a living yet it is asked in interviews anyway, so nah, we don't have to use AI in interviews.

You’ve just written the exact reason LeeteCode is widely mocked as an interview technique. They are not representative of most real world software, and engineers that train to solve them give a false impression of their ability to solve most other problems. I’ve interviewed hundreds of engineers for software and hardware roles. A good coding test is based on self-contained problems that the team actually encountered…

Leetcode's utility is not in showing you can solve real-world problems. It's used as a baseline to estimate how smart you are. Every shop prides itself on hiring smart people, and some only want the best of the best—your MIT and Stanford grads, etc. A smarter engineering workforce can not only solve the problems you have, they're better positioned to spot and avoid problems you haven't anticipated yet. Anyways, IQ testing as a condition of employment can open you up to legal liability, as IQ tests are horribly racist. Leetcode is a way around that.

Re: Beyond agentic coding

#88

Post by port11 »

andai wrote: post #19

I wonder if the problem of idle time / waiting / breaking flow is a function of the slowness. That would be simple to test, because there are super fast 1000 tok/s providers now. (Waiting for Cerebras coding plan to stop being sold out ;) I've used them for smaller tasks (making small edits), and the "realtime" aspect of it does provide a qualitative difference. It stops being async and becomes interactive. A suffici…

Waiting on AI is its own category, so I’m not entirely sure what ‘idle time’ means. Of course we could just go and read that study…

Re: Beyond agentic coding

#89

Post by roughly »

pringk02 wrote: post #29
roughly wrote: post #20

The “Calm technology” thing always annoys me, because it skips every economic, social, and psychological reason for the current state of affairs and presents itself as some kind of wondrous discovery, as opposed to “the way things were before we invented the MBA.” A willing blindness to predators doesn’t provide a particularly useful toolkit.

I would be interested to hear you elaborate on this more. I feel like I almost get what you are saying but am not confident I actually understand.

Yeah, so - the whole Calm Technology(™) feels like someone looked at the dopamine casino of modern tech and said "well, this is all wrong" - which, yes - and then proceeded to try to treat it like a design problem, which it is emphatically not. Not only are the people who made the dopamine casino aware of what makes "calm technology"(™), they're experts in it, because the entire design process of most modern tech is explicitly designed not to be "calm," because the entire economic incentive structure is pushing dopamine casinos. People aren't building "uncalm" technology by mistake, they're building it because the modern tech business structure and environment rewards addictive software.

If the "Calm Tech"(™) people/institute/whatever actually wanted to move the needle, they'd be lobbying for regulations, building tools for consumers to fight back, or trying to do anything at all that actually shifts the underlying institutional and incentive structures. As it sits, they're the equivalent of a recess monitor suggesting maybe the bully would be happier if he shared the toys with the other kids - and frankly, given the degree of branding around the whole thing, it all starts to smell more like "influencer" than "genuine attempt to improve technology."

Re: Beyond agentic coding

#90

Post by OutOfHere »

XenophileJKO wrote: post #18
OutOfHere wrote: post #3

Agentic coding doesn't make any sense for a job interview. To do it well requires a detailed specification prompt which can't reliably be written in an interview. It ideally also requires iterating upon the prompt to refine it before execution. You get out of it what you put into it.

As someone that agenticly codes A LOT. Detailed specs are not required, but certainly one way to use the systems. If you are going to do a big build out of something, spec up front at least to have a clear idea of the application architectural boundaries. If you are adding features to a mature code base, then the general order of the day is: First have the Ai scout all the code related to the thing you are changing.…

There is a real danger here during an interview of unfairly imposing one's style on others. I think it's great to share one's approach, but making it the only approach can lead to stagnation and lose out on picking ideas from alternatives.
Post reply on HN