Live data from Hacker News

Beyond agentic coding

haskellforall.com

31–40 of 96 posts

Re: Beyond agentic coding

#31
The "junior dev" analogy is the one I keep coming back to, but the part people miss is the review surface area problem.

When a human junior writes code, they leave breadcrumbs of their thinking — commit messages, PR descriptions, comments explaining why they chose approach A over B. You can reconstruct their reasoning from the artifact trail.

Agents don't do this naturally. You get a diff with no context for why it went that direction. So the reviewer has to reverse-engineer the thinking from the code alone, which is actually harder than reviewing human code because there are no "tells" — no familiar coding style, no consistent patterns that hint at the developer's mental model.

The semi-auto approach mentioned upthread works precisely because it solves this: you were there for every decision, so there's nothing to reconstruct. The productivity loss from staying in the loop is offset by the time you save not having to audit opaque changes after the fact.

Re: Beyond agentic coding

#32
> I believe there is a lot of untapped potential in AI-assisted coding tools

Yikes.

By the way, the whole website is strange. Just the name alone "haskell for all".

Many years ago when I tried to learn Haskell (and wrote some haskell code that worked but it was sooooo much harder when compared to ruby or python), one of the few things that appeared early on, aside from the monad barrier, was that many haskell people said that Haskell is deliberately not for everyone. Back then this was when IRC was still en vogue, so I "heard" that via various discussions on #haskell.

I did not fully understand this part, because ... why would you write a language that only a few big brain people could use? I found that elitistic and snobbish, even arrogant.

Only at a later time did I understand one part of the meaning. The "we don't want you here" also means "we don't want YOU to change haskell into some other new meta-variant". I understood this much better when some guys wanted to have ruby embrace types. Then I understood that people not only want to change a language but also want to ruin it; whether on purpose or because they prefer something else (such as their brain embraced types-only code bases) is a separate discussion. I still find the haskell attitude very elitistic but I at the least understand that they don't want everyone to use - and change - Haskell.

> For example, someone who was new to Haskell could edit a Haskell file “as Python” and then after finishing their edits the AI attempts to back-propagate their changes to Haskell.

I like the general idea behind "write in any language, have it work in EVERY language". But the whole AI movement seems more about trying to dumb down people really or make them lazy, in many ways. I have seen people use it to great effect, so I am not at all saying AI has no use cases. What I am however had noticing is that it made many normal folks super-lazy. They type on their smartphone, solution comes out, task finished, move on. That's not necessarily only bad, but it comes with trade-offs. My approach is much slower, but it is systematic and I am in full control of what is documented how and where.

> This is obviously not a comprehensive list of ideas, but I wrote this to encourage people to think of more innovative ways to incorporate AI into people's workflows

Oh he has achieved this in a different way. Now I have another reason to not want AI in my "workflows". The whole website also seems super-strange to me. Has he used AI to write the whole content and layout? It's hard to say because I don't know how it used to be in the past, but the paragraphs and the content seem so strange. I suspect he used AI to generate the layout too; and some of the content as well. We are losing "interaction" with real humans here too (ok ok, there is not a lot of interaction with regards to a static website, but if a blog is written by AI, then that is not really any possibility for interaction with a human - you could not even distinguish WHO wrote the content or made the decisions such as which style to choose and so forth; it looks very fake to me or, at the least, in part. I typically don't see this with other blogs.).

Re: Beyond agentic coding

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

Is the article good? I found it of a surprisingly poor quality. Is my assessment incorrect? Basically it is an article that tries to convince people of how relevant AI is nowadays. I don't really see it like that at all and none of the "arguments" I found convincing.

Re: Beyond agentic coding

#34

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]

I totally get your point and agree to an extends, though I have not yet been able to create that trust with the LLM. With human teams, yes, with LLMs, feels like I still have to verify too much.

Re: Beyond agentic coding

#35
post #8

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.

How about bug fixing? Give someone a repo with a tricky bug, ask them to figure it out with the help of their coding agent of choice.

It doesn't have to be a "tricky" bug. A straightforward bug will do. If it's too tricky, the logic could be better off being rewritten.

Re: Beyond agentic coding

#36

> I believe there is a lot of untapped potential in AI-assisted coding tools Yikes. By the way, the whole website is strange. Just the name alone "haskell for all". Many years ago when I tried to learn Haskell (and wrote some haskell code that worked but it was sooooo much harder when compared to ruby or python), one of the few things that appeared early on, aside from the monad barrier, was that many haskell people…

Author here: my pronouns are she/her

I did not use AI to generate my blog's content nor layout.

Also, the reason my blog is named "Haskell for all" is because I originally created my blog a long time ago to try to make Haskell more accessible to people and counter the elitist tendencies.

Re: Beyond agentic coding

#37
post #21
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…

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 aggressively, but collaboration introduces checkpoints. Reviewers need time to reconstruct intent, not just verify correctness. If the rate of change exceeds the team’s ability to form that understanding, friction increases: longer reviews, more rework, or a tendency to rubber-stamp changes.

This suggests a practical ceiling where individual "power coding" outpaces team coherence. Past that point, gains need to come from improving shared artifacts rather than raw output: clearer commit structure, smaller diffs, stronger invariants, better automated tests, and more explicit design notes. In other words, the limiting factor shifts from generation speed to synchronization quality across humans.

Re: Beyond agentic coding

#38
"I allow interview candidates to use agentic coding tools and candidates who do so consistently performed worse"

I have a similar impression. It seems to me that people get something that kind of works and then their interest runs out and they're left with a shallow understanding of the result and how it might be achieved. This seems detrimental to learning, which tends to happen when one is struggling.

"I strongly believe that chat is the least interesting interface to LLMs"

This is also something I agree with. When I work with databases, the best part is not sitting with an immediate client writing raw queries by hand.

Re: Beyond agentic coding

#39
post #30

“Facet-based project navigation You could browse a project by a tree of semantic facets. For example, if you were editing the Haskell implementation of Dhall the tree viewer might look like this prototype I hacked up2” ^ This is a genius idea - someone add this to claude

At work we use Clean Architecture which is incredibly hard to browse, even though I've been there for 6+ months now and know where everything is, I have to use so much working memory to gather together the files for a feature slice (endpoint, command, command handler, etc).

I've thought for a while of building this exact thing as a vscode extension because of how utterly shit it is :D

I really want the source code!

Re: Beyond agentic coding

#40

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.

>which can't reliably be written in an interview Why not? It sounds like a skill issue to me. >It ideally also requires iterating upon the prompt to refine it before execution. I don't understand. It's not like you would need to one shot it.

It's a time issue. Interviews hardly offer much time as it is. To ask for something that benefits from multiple iterations is probably not going to fit in the available time.
Post reply on HN