Earlier quoted context omitted.
GOTO3 and loop? Don't you mean GOTO2 and loop ;)
At the moment the list goes 1, 2, 2, 3…
See what happens when I don’t use AI lol. Should be 4
Reflections on software engineering in the age of AI
61–70 of 110 posts
Re: Reflections on software engineering in the age of AI
#62Earlier quoted context omitted.
| type errors, scope issues, import resolution, dependencies. I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs: 1. Don't use it to write code. It's a terrible programmer. But it's an intelligent rubber duck and a solid analysis tool. 2. Write the code yourself. It'll go faster than figuring it out as you go along. It's just typing if yo…
> Don't use it to write code. It's a terrible programmer. I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
I think a lot of the people saying AI code sucks is because the code isn't formatted the way they like, not because the code doesn't work.
Basically, the people that leave dozens of bikeshed code review comments.
Sure, sometimes I might ask the AI to break out a helper function or structure things differently, but that's the same as working with another dev
Re: Reflections on software engineering in the age of AI
#63"you haven’t done any of the hard thinking you would normally do in writing the code yourself" It's true, I spend less time solving problems that arise naturally from the process of implementation. But implementation errors have a poor signal-to-noise ratio. For every error that exposes a real design problem there are 10 others that involve routine fixes: type errors, scope issues, import resolution, dependencies. Th…
| type errors, scope issues, import resolution, dependencies. I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs: 1. Don't use it to write code. It's a terrible programmer. But it's an intelligent rubber duck and a solid analysis tool. 2. Write the code yourself. It'll go faster than figuring it out as you go along. It's just typing if yo…
> Don't use it to write code
One of the things I've started doing is to write the high level scaffold myself, create stubs (with comments) and have it fill out the details. I haven't done this for long, but I feel like my mental model of the code rots less, and I can review code faster.
I used to do this in the past, when these models were not all that capable, now there is a huge temptation to leave everything to the model. But long term I lose track of whats going on, and have a hard time even communicating with the model about the changes I want. Just a total decay of my mental model of the system, and it's really hard to recover from that state.
Re: Reflections on software engineering in the age of AI
#64"you haven’t done any of the hard thinking you would normally do in writing the code yourself" It's true, I spend less time solving problems that arise naturally from the process of implementation. But implementation errors have a poor signal-to-noise ratio. For every error that exposes a real design problem there are 10 others that involve routine fixes: type errors, scope issues, import resolution, dependencies. Th…
Business has tried and mostly failed to do this since the beginning of programming. Architects that stop coding long enough tend to become shitty architects as their abstractions increasingly become disconnected from the concrete requirements of the actual problem space rather than the idealized version in their head.
Re: Reflections on software engineering in the age of AI
#65Earlier quoted context omitted.
> Don't use it to write code. It's a terrible programmer. I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
> I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience If you see people saying it often, but you are convinced they are just feeling threatened, what AI generated software would point to to say, "Look at this! Definitive evidence that they are just coping!"
GitHub
/s
Re: Reflections on software engineering in the age of AI
#66> AI does not know whether the code it just added violates some legal requirement to which your product is subject.
The rest of the paragraph is a list of similar complaints.
All of these can be codified - the new work is the (fascinating!) challenge of working out how and codifying them, then giving the codified checker logic to the agent to run at will - thus taking yourself out of all of those loops.
They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it.
As a result, you’re only being effective if you can engineer (not hack, not vibe) an agent that can produce work your company can use with as little cleanup as possible - and with less cleanup over time.
You get job by codifying what you know - what most don’t account for is that there’ll never be a limit to what there is to know, and codifying expertise will be challenging for a long time to come.
Re: Reflections on software engineering in the age of AI
#67How does Andrew manage being a full-time software developer and an author? Both jobs are so cognitively demanding.
It is extremely mentally demanding to do both, even for someone with an overactive brain. I reached a point of severe burnout in 2025 and cut back to part-time work. I'll have to ramp up my hours again soon because, contrary to one of the other comments, I didn't get rich during 1990s/2000s boom. As for how I did it, I would wake up very early and put in a few hours of writing, then I would put in a full day's work a…
Thanks for this. I've been trying to learn this writing thing on top of my full-time job and it's been a struggle. It's helpful to hear how you managed it.
Re: Reflections on software engineering in the age of AI
#68I’ve been successfully shipping software since 1998. I just got the first payment on a greenish-field software product I’m doing on the side solo (that I couldn’t have done solo in 2019 without the tools). This is my workflow: 1. Client asks you to add a feature(s) 2. Spend two weeks unpaid walking the client through scoping down to the most minimal viable set of features that tests the business hypothesis and roadma…
Part 6 to me seems always totally useless. Whenever I let these tools look at existing repos they are too influenced by what's already there. I could even say "feel free to completely refactor or rewrite anything" and they'll still just do small performative changes. I've now changed my workflow to only using AI for prototyping and rewriting by hand once I can see something is viable. Takes longer but the results are…
I don’t have those problems
You have to build your architecture modularly so you’re never having to reason about more than the schema and api-contracts for IPC
Re: Reflections on software engineering in the age of AI
#69Writing and coding are not the same thing; coding is a means to an end, since you don’t use the code, you use the software. This means the mechanism by which the code was created is orthogonal to the software as you’d experience it as a user.
There are many reasons to curate what goes into the software - for example, if it must be maintainable, if it must conform to standards that cannot be fully codified into the software (eg. regulatory requirements), or if you just really darn well like writing code!
But it takes a mountain of code to make an outwardly simple thing so why not use a work-amplifying tool to produce that code and get to working software more cheaply.
On the other hand writing is the act of creating the exact product that will be consumed. Every detail matters and there’s no leverage to trying to write faster.
So it’s a false equivalence. Hopefully I’ve elucidated the subtlety.
Re: Reflections on software engineering in the age of AI
#70The only reflection that matters, now, is that every company that sells software for money is now a confidence game. How long can you con your users into believing they have any reason not to type the 5-word prompt “recreate make no mistakes” and cut you, the middle man, out?