Live data from Hacker News

Using AI to write better code more slowly

nolanlawson.com

141–150 of 511 posts

Re: Using AI to write better code more slowly

#141
post #59

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds cor…

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

I follow the same process. I have a design in mind for the problem at hand, but I don't reveal it to Codex. I go back and forth a bit to see if its proposals are better than mine. I go back and forth on tradeoffs of various approaches. And then I ask it to compare its proposals with mine. I "win" most of the time but there are many times where it shows a me a better, or simpler approach, or makes me rethink the solution altogether.

Once this is done, the mechanical coding parts are mostly routine (for codex)

Re: Using AI to write better code more slowly

#142
post #133

Basically you're using AI as very costly linters... what's wrong with (depending on the language) checkstyle, sonarlint, ruff, mypy, xmllint, and/or eslint?

The quick answer is that even in the workflow described by the author these tools don’t do the same thing AI does. And a good programmer/agent will be using these tools as well

Re: Using AI to write better code more slowly

#143

Earlier quoted context omitted.

You've essentially promoted yourself from coder to engineering manager, trading syntax fatigue for the mental marathon of refereeing specialized AI developers to ship v3-quality code on the first try.

Indeed. AI is bumping everyone up to manager level, and having dealt with long PR feedback cycles with humans for years - I don't mind the promotion. Also shipping a v3 is so much nicer than shipping a v1 and dealing the all the corner cases in production. Before AI, myself and everyone else I knew was drowning in tech debt. And now with AI we are treading water.

It's bumping to manager level, except without the 1:1s, quarterly/yearly planning, headcount and budget reviews, org/reorg discussions, performance calibration, and OKR planning. No complaints about the last review cycle or about the upcoming one.

Re: Using AI to write better code more slowly

#145
post #128
post #59

Earlier quoted context omitted.

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

How would you approach this problem if you are let's say token constrained due to per month limits set in your company? What I've tried to do is make the bot write detailed spec documents, slowly building it over time as I explain the full problem. It works for the most part but it's you have some non standard requirement, the agent seems to skip over that part of the spec document when it starts to code. Or it would…

In my book, the single most effective way to spend tokens is having it review code/specs you've written. One advantage to putting the ai in that position is that unreliable competence isn't much of a problem as you can ignore bad suggestions.

I would also recommend explaining the specs and doing a lot of your back and forth with a lower end model and set it to a higher end model only once the conversation history has all the context you feel the higher end model needs.

Re: Using AI to write better code more slowly

#146

I use cheaper models (Deepseek is king, but GLM and Kimi as well) and do the planning myself. I often start a task myself, write some code to get the LLM on the right track, and then have it complete parts of the implementation that are kind of boring or repetitive. LLM's are just next token predictors, I don't mean that in a demeaning way, but I've found if I can get the LLM started on the right track with my own co…

What app do you use with deepseek? I've been used claude code but pointing it at the deepseek api and it works ok, but I'm wondering if there are better options. ( https://api-docs.deepseek.com/quick_start/agent_integrations... )

I've been using Zed and Charm Crush. I think most work with it though, any agent designed around OpenAI completions API compat will do fine. Although Zed had some problems initially with tool calls but it seems to be fixed.

I'm working on my own harness to be a bit more aligned with my workflow but tbh I'm losing motivation since other harnesses are fine now. I could probably vibe code something but there's not much point imo. Unless I come up with something completely different but who knows.

I think there is a Deepseek agent out there in Rust, but I've never tried it. Zed has been pretty decent with all models, not the best but certainly beats VSCode. ChatGPT 5.4 on that calls about 100 different git diffs to "verify" the changes are valid which is rubbish. I haven't tried Deepseek with it though.

Honestly these models and agents are becoming commodities, as long as they don't totally fail with tool calling or some stupid system instructions the models can figure stuff out pretty well.

Re: Using AI to write better code more slowly

#147

Earlier quoted context omitted.

congratulations on your soon to be coming burnout. Keeping that many tasks in parallel, running all the time will kill you.

> congratulations on your soon to be coming burnout. Multitasking does not mean burnout. It just means you are not wasting time while idling. Multitasking was not invented for AI coding assistants. What do you think feature branches are used for?

The constant context changes, mental overload, inability to focus on one thing and do it well is exactly what every software developer has been fighting against for the past thirty years because it leads to shit quality and burns you out. You're automating the burnout. Idling is a necessity, not an illness.

Your feature branch is to put things aside and send them to CI, or wait and think on them. Not to have four of them running in parallel in your head frying you.

Re: Using AI to write better code more slowly

#149
We may be in the last Golden age of AI, where experienced professionals still exist who can code manually, and AI already exists who can code automatically, and when the former use the latter skillfully, wonders happen. This magical intersection may not exist iin the future, or become very rare.
Post reply on HN