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.
> 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.
I tried to approach it that way as well, but I am realizing when I let the agent do the implementation, even with clear instructions, I might miss all the “wrong“ design decisions it takes, because if I only review and do not implement I do not discover the “right“ way to build something. Especially in places where I am not so familiar myself — and those are the places where it is most tempting to rely on an agent.
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.
> Post had nothing to do with Haskell so the title is a bit misleading.
To be fair, that's not part of the article's title, but rather the title of the website that the article was posted to.
I know, but that's not typically how you see titles posted here. I'm just disappointed as I enjoy writing Haskell. :)
I was excited to see a non-AI article on this site for once. Oh well.
It was a good article though
Programming languages are most interesting area in CS for the next 10 years. AI need criteria for correctness that can't be faked so the boundary between proof verification and programs will become fuzzier and fuzzier. The runtimes also need support for massively parallel development in a way that is totally unnecessary for humans.
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.
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.
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.
In the Before Times we used to do programming interviews with “you can use Google and stack overflow” for precisely this reason. We weren’t testing for encyclopaedic knowledge - we were testing to see if the candidate could solve a problem.
But the hard part is designing the problem so that it exercises skill.
>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.
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.
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.
> 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.
I tried to approach it that way as well, but I am realizing when I let the agent do the implementation, even with clear instructions, I might miss all the “wrong“ design decisions it takes, because if I only review and do not implement I do not discover the “right“ way to build something. Especially in places where I am not so familiar myself — and those are the places where it is most tempting to rely on an agent.
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.
> Post had nothing to do with Haskell so the title is a bit misleading.
To be fair, that's not part of the article's title, but rather the title of the website that the article was posted to.
I know, but that's not typically how you see titles posted here. I'm just disappointed as I enjoy writing Haskell. :)
I was excited to see a non-AI article on this site for once. Oh well.
It was a good article though
Programming languages are most interesting area in CS for the next 10 years. AI need criteria for correctness that can't be faked so the boundary between proof verification and programs will become fuzzier and fuzzier. The runtimes also need support for massively parallel development in a way that is totally unnecessary for humans.
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.
https://www.dev-log.me/pr_review_navigator_for_claude/
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.
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.
In the Before Times we used to do programming interviews with “you can use Google and stack overflow” for precisely this reason. We weren’t testing for encyclopaedic knowledge - we were testing to see if the candidate could solve a problem.
But the hard part is designing the problem so that it exercises skill.
>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.
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.