alt Hacker NewsBeyond agentic coding
Comments
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 sufficient shift in quantity produces a phase shift in quality.
--
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.
The most enjoyable way I've found of staying synced is to stay in the driver's seat, and to command many small rapid edits manually. (i.e. I have my own homebrew "agent" that's just a loop of, I prompt it, it proposes edits, I accept or edit, repeat.)
So then the "synchronization" of the mental state is happening continuously, because there is no opportunity for desynchronization. Because you are the one driving. I call that approach semi-auto, or Power Coding (akin to Power Armor, which is wielded manually but greatly enhances speed and strength).
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.
What I've found is that most people who dislike the chat interface aren't using it in a way that leverages its strengths.
Up until recently, LLMs just plain sucked. You'd set them on a task and then spend hours hand-holding them to output something almost correct.
Nowadays you can have a conversation with the chatbot, hash out a design, rubber duck and discuss what-ifs until you have a solid idea of the thing you're building, codified in a way an agent could understand, and now you have a PLAN.
From there, it's a matter of setting the agent in motion and checking from time to time to make sure it's not getting stuck on something under-specified.
That said, I've found that this kind of workflow works a lot better with claude than with gemini.
I have the same feeling recently that we should focus more on using AI to enable us, to empower us to do the important things. Not take away but enhance, boring , clear boilerplate yes, design decisions no. And making reviewing easier is a perfect example of enhancing our workflow. Not reviewing for us, but supporting us.
I am recently using this tiny[1] skill to generate an order on how to review a PR and it has been very helpful to me.
The review ordering problem is less about AI generation and more about graph traversal. Every diff already encodes a dependency graph (imports, function calls, type references), and optimal review order is just a topological sort weighted by cognitive load. GitHub's alphabetical ordering is zero-information when we have the full call graph. The hard part isn't producing the ordering — it's efficiently extracting and maintaining the dependency graph as code changes.
I have been considering what it would be like to give each function name a specific color and a color for each variable's type followed by a color derived from the hash of the symbol name and keywords would each be their specific type. And essentially printing a matrix of this, essentially transforming your code into a printable matrix "low-lod" or "mipmap" form. This could be implemented like the VSCode minimap but I the right move here is to implement it as a hook that can modify the output of your agent. That way you can look at the structure of the code without reading the names in particular.
I whole heartedly prefer chat interfaces over inline ai suggestions.
I find the inline stuff so incredibly annoying because they move around the text I am looking at.
I really like the "file lens" example:
> “Focus on…” would allow the user to specify what they're interested in changing and present only files and lines of code related to their specified interest.
> “Edit as…” would allow the user to edit the file or selected code as if it were a different programming language or file format.
Generally agree with the idea of calm technology, but I feel like inlay hints are a bad example. They actively give me anxiety because it makes the code feel harder to read, it takes my attention away from the code, and it feels more awkward to edit the text because you have these virtual characters getting in the way and having to re-render as you type, causing a shift in your cursor position. It's not at all calming for me, lol.
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.
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.
All the problems highlighted with agentic coding are problems you face when working as a team of humans. Apply the same principles:
- Break down big problems into smaller ones
- Create extensive plan + documentation (context)
- Make sure some parts of the plan if possible can be done simultaneously and not create too many dependencies.
- Define success criteria (tests?)
Then just unleash the agents. The more you put in, the more you get out.
This is an amazing article. The HN title should be edited a bit. "Calm Technology - Beyond Agentic Coding"
I did a bit of digging into why you think agentic coding is “not there yet”, and I think you are bashing a tool you have very little experience with and are using a bit wrongly.
Nothing wrong with that, except that as opposed to any other tool that is out there, agentic coding is approached by smart senior engineers that would otherwise spend time reading documentation and understanding a new package/tool/framework before giving conclusions around it with “I spun up Claude code and it’s not working”. Dunno why the same level of diligence isn’t applied to agentic coding as well.
First question that I always have to such engineers is “what model have you tried?” And it always ends up being the non-SOTA models for tasks that are not simple. Have you tried Claude Opus?
Second question: have you tried plan mode?
And then I politely ask them to read some documentation on using these tools, because the simplicity of the chat interface is deceptive.
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 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.
“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
find the reflections in the rushing river
> 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.
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.
I agree agents can break flow but I think the bigger issue is they hide too much, not that they're too intrusive.
Most agent tools right now don't give you good visibility into what sub-agents are doing or what decisions they're making. You zoom out, let it run, come back to a mess. Tools like OpenCode and Amazon's CLI Agent Orchestrator are trying to fix this - letting you watch what each agent is actually doing and step in to correct or redirect.
OpenCode actually removed the ability to message sub-agents directly. I get why - people would message one after it finished, the conversation would fork off, and the main orchestrator lost track. But I don't love that fix because being able to correct or pivot a sub-agent before it finishes was genuinely useful. They bandaided a real problem by removing a good feature.
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 that's where things fall apart.
So I wouldn't want agent tools to be "calm" and fade into the background. I want full transparency into what they're doing at all times because that's how you catch wrong turns early. The tooling is still early and rough but it keeps getting better at supporting experts rather than trying to replace them.
[dead]
> 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.).
> 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.