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

41–50 of 96 posts

Re: Beyond agentic coding

#41

Post by BitsAndObjects »

tuhgdetzhh wrote: post #37
dybber wrote: post #21

Earlier quoted context omitted.

You still have to synchronize with your code reviewers and teammates, so how well you work together in a team becomes a limiting factor at some point then I guess.

Yes, and that constraint shows up surprisingly early. Even if you eliminate model latency and keep yourself fully in sync via a tight human-in-the-loop workflow, the shared mental model of the team still advances at human speed. Code review, design discussion, and trust-building are all bandwidth-limited in ways that do not benefit much from faster generation. There is also an asymmetry: local flow can be optimized a…

This thread seems to have re-identified Amdahl’s law in the context of software development workflow.

Agentic coding is only speeding up or parallelising a small part of the workflow - the rest is still sequential and human-driven.

Re: Beyond agentic coding

#42

Post by BitsAndObjects »

adhamsalama wrote: post #16
zarzavat wrote: post #10

Earlier quoted context omitted.

In the UK the driving test requires a portion of driving using a satnav, the idea being that drivers are going to use satnavs so it's important to test that they know how how to use them safely. The same goes for using Claude in a programming interview. If the environment of interview is not representative of how people actually work then the interview needs to be changed.

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 while developing our product. Boil the problem down to its core, create a realistic setup that reflects the information the team had when they encountered the challenge, and then ask the candidate to think it through. It doesn’t matter if they only write notes or pseudo code, and it doesn’t matter if they reach the wrong conclusion. What it’s testing for is the thought process. The fact the candidate has to ask the interviewer questions as though the interviewer is effectively the IDE, is great! The interviewer experiences the engineer’s thought process first-hand. And the interviewer can nudge the candidate in the correct direction by communicating answers that aren’t just typical IDE error messages.

To validate these kinds of questions in advance, I’d often run them on existing team members that hadn’t already been exposed to the real challenge the problem was based on.

Re: Beyond agentic coding

#43

Post by zozbot234 »

tuhgdetzhh wrote: post #37
dybber wrote: post #21

Earlier quoted context omitted.

You still have to synchronize with your code reviewers and teammates, so how well you work together in a team becomes a limiting factor at some point then I guess.

Yes, and that constraint shows up surprisingly early. Even if you eliminate model latency and keep yourself fully in sync via a tight human-in-the-loop workflow, the shared mental model of the team still advances at human speed. Code review, design discussion, and trust-building are all bandwidth-limited in ways that do not benefit much from faster generation. There is also an asymmetry: local flow can be optimized a…

You can ask the agent to reverse engineer its own design and provide a design document that can inform the code review discussion. Plus, hopefully human code review would only occur after several rounds of the agent refactoring its own one-shot slop into something that's up to near-human standards of surveyability and maintainability.

Re: Beyond agentic coding

#44

Post by WilcoKruijer »

> You could take an editor session, a diff, or a pull request and automatically split it into a series of more focused commits that are easier for people to review. This is one of the cases where the AI can reduce human review labor

I feel this should be a bigger focus than it is. All the AI code review start up are mostly doing “hands off” code review. It’s just an agent reviewing everything.

Why not have an agent create a perfect “review plan” for human consumption? Split the review up in parts that can be individually (or independently) reviewed and then fixed by the coding agent. Have a proper ordering in files (GitHub shows files in a commit alphabetically, which is suboptimal), and hide boring details like function implementations that can be easily unit tested.

Re: Beyond agentic coding

#45

Post by camgunz »

The only way AI companies can recover their capex is to replace workers. That's why their interfaces are only facially built for the workers they're replacing (engineers, finance, etc) and why this is a non-starter: it totally undermines the business model.

Re: Beyond agentic coding

#47

Post by brightstep »

> 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.

Re: Beyond agentic coding

#48

Post by refactor_master »

Zakodiac wrote: post #27
wazHFsRy wrote: post #15

Earlier quoted context omitted.

> Honestly the model that works best for me is treating agents like junior devs working under a senior lead. The expert already knows the architecture and what they want. The agents help crank through the implementation but you're reviewing everything and holding them to passing tests. That's where the productivity gain actually is. When non-developers try to use agents to produce entire systems with no oversight tha…

[dead]

It’s interesting then to ask if this will behave the same as big orgs? Eg once your org is big and settled, anything but the core product and adjacent services become impossible, which is why 23 often see a 50-person company out-innovating a 5k person company in tech (only to be bought up and dismantled, of course, but that’s besides this point).

Will agents simply dig the trenches deeper towards the direction of the best existing tests, and does it take a human to turn off the agent noise and write code manually for a new, innovative direction?

Re: Beyond agentic coding

#49

Post by nakedneuron »

Insanity wrote: post #2

Post had nothing to do with Haskell so the title is a bit misleading. But rest of article is good, and I actually think that Agentic/AI coding will probably evolve in this way. The current tools are the infancy of AI assisted coding. It’s like the MS-DOS era. Over time maybe the backpropagating from “your comfort language” to “target language” could become commonplace.

Agree. Gist of the FA is about "calm technology". Title should reflect it better.

Also agree on everything author mentions. I can't attest to all examples but I know what a UI is.

Author mentions center of focus of attention. We should hear more often about the periphery of our attention field. Its bandwidth so to speak is a magnitude lower compared to the center but it's still there and can guide some decisions quite unintrusively to flow.

(Major) eye movements are a detriment to attention, which itself should be treated like a commodity (in case of a UI thousands use, moreso like a borrowed commodity).

Post reply on HN