[using an lmm as stack overflow]

even if you check and redo after paste, you need to check for gotchas. I wish I had a nickel for every time the llm gave me a solution with a hidden limitation. assume that it violates all your unspoken assumptions, and adheres only to what you nailed down in your prompt

Hi i5heu. Given that you seem to use AI tools for generating images and audio versions of your posts, I hope it is not too rude to ask: how much of the post was drafted, written or edited with AI?

The suggestions you make are all sensible but maybe a little bit generic and obvious. Asking ChatGPT to generate advice on effectively writing quality code with AI generates a lot of similar suggestions (albeit less well written).

If this was written with help of AI, I'd personally appreciate a small notice above the blog post. If not, I'd suggest to augment the post with practical examples or anecdotal experience. At the moment, the target group seems to be novice programmers rather than the typical HN reader.

First article about writing code with AI i can get behind 100%. Stuff i already do, stuff i've thought about doing, and at ideas i've never thought doing ("Mark code review levels" especially is a _great_ idea)

All this boils down to is that AI wins when it amplifies engineers, not replaces them. And the best code still comes from devs who ultrathink.

Why shallow and likely generated posts of a “Knowledge Management Advocate” get so many stars on hn?

Just because of a hype?

I want to give a try to gsd + open code + Cerebras code. Any experience?

Ah yes, to have AI write code for you, you simply just need to, let's see ..

"Document the requirements, specifications, constraints, and architecture of your project in detail. Document your coding standards, best practices, and design patterns. Use flowcharts, UML diagrams, and other visual aids to communicate complex structures and workflows. Write pseudocode for complex algorithms and logic to guide the AI. Develop efficient debug systems for the AI to use. Build a system that collects logs from all nodes in a distributed system and provides abstracted information. Use a system that allows you to mark how thoroughly each function has been reviewed. Write property based high level specification tests yourself. Use strict linting and formatting rules to ensure code quality and consistency. Utilize path specific coding agent prompts. Provide as much high level information as practical, such as coding standards, best practices, design patterns, and specific requirements for the project. Identify and mark functions that have a high security risk, such as authentication, authorization, and data handling. Make sure that the AI is instructed to change the review state of these functions as soon as it changes a single character in the function. Developers must make sure that the status of these functions is always correct. Explore different solutions to a problem with experiments and prototypes with minimal specifications. Break down complex tasks into smaller, manageable tasks for the AI. You have to check each component or module for its adherence to the specifications and requirements."

And just like that, easy peasy, nothing to it.

As a supreme irony, the story currently on the front page directly under this one ('You are here'), makes the claim "The cost of turning written business logic into code has dropped to zero. Or, at best, near-zero." in the very first sentence.

In her defence, I use most of those strategies myself as well...

You must know the stack, architecture, and approve manually. Otherwise, at this stage of AI development, the code becomes unmaintainable.

> Use strict linting and formatting rules to ensure code quality and consistency. This will help you and your AI to find issues early.

I've always advocated for using a linter and consistent formatting. But now I'm not so sure. What's the point? If nobody is going to bother reading the code anymore I feel like linting does not matter. I think in 10 years a software application will be very obfuscated implementation code with thousands of very solidly documented test cases and, much like compiled code, how the underlying implementation code looks or is organized won't really matter

I don’t understand the interest in “quality code.” I never need to look at the code itself. I just make sure it runs right.

How to write good code with AI -> put in as much effort as you did before on 20% more code than you used to work with.

attention is all AI needs

That sounds like the advice of someone who doesn't actually write high-quality code. Perhaps a better title would be "how to get something better than pure slop when letting a chatbot code for you" - and then it's not bad advice I suppose. I would still avoid such code if I can help it at all.

My tricks:

Define data structures manually, ask AI to implement specific state changes. So JSON, C .h or other source files of func sigs and put prompts in there. Never tried the Agents.md monolithic definition file approach

Also I demand it stick to a limited set of processing patterns. Usually dynamic, recursive programming techniques and functions. They just make the most sense to my head and using one style I can spot check faster.

I also demand it avoid making up abstractions and stick to mathematical semantics. Unique namespaces are not relevant to software in the AI era. It's all about using unique vectors as keys to values.

Stick to one behavior or type/object definition per file.

Only allow dependencies that are designed as libraries to begin with. There is a ton of documentation to implement a Vulkan pipeline so just do that. Don't import an entire engine like libgodot.

And for my own agent framework I added observation of my local system telemetry via common Linux files and commands. This data feeds back in to be used to generate right-sized sched_ext schedules and leverage bpf for event driven responses.

Am currently experimenting with generation of small models of my own data. A single path of images for example not the entire Pictures directory. Each small model is spun akin to a Docker container.

LLMs are monolithic (massive) zip files of the entire web. No one really asking for that. And anyone who needs it already has access to the web itself

TLDR: Know what you are doing and outsource the typing to LLM

AI slop article. Just show me the prompt.

I agree, but i'm shouting at the cloud. Stuff needs to be done, it seems to work at first, so either i just abandon quality and let things rot, or i read everything and underline each time the code smell.

I too use AI, but mostly to generate scripts (the most usefull use of AI is 100-200 line scripts imho), test _cases_ (i write the test itself, the data inside is generated) and HTML/CSS/JS shenanigans (the logic i code, the presentation i'm inferior to any random guy on the internet, so i might as well use an AI). I also use it for stuff that never end in repository, for exploration/proof of concept and outside of scope tests (i like to understand how stuff work, that helps), or to summarize Powerpoint presentations so i can do actual work during 60-person "meetings" and still get the point.

When is the last time someone said that, motivating you to try the latest model? If it was 6 or more month ago, my reply is that the sentiment expressed was partially incorrect in the past, but it is not incorrect now. If a conspiracy theorist is always wrong about a senior citizen being killed, that does not make the senior immortal.

Brand new projects have a way of turning into legacy codebases

What are you talking about? Exploring and explaining the legacy codebases is where they shine, in my experience.

Yes it did, it provided 12 things that the author asserts helps produce quality code. Feel free to address the content with something productive.

Where is all the amazing software and/or improvements in software quality that is supposed to be coming from this revolution?

So far the only output is the "How I use AI blogs", AI marketing blogs, more CVEs, more outages, degraded software quality, and not much of shipping anything.

Is there any examples of real products and not just anecdotes of "I'm 10x more productive!"?

Its only revolutionary if you think engineers were slow before or software was not being delivered fast enough. Its revolutionary for some people sure, but everyone is in a different situation, so one man's trash can be other man's treasure. Most people are treading both paths as automation threatens their livelihood and work they loved, also still not able to understand why would people pay to companies that are actively trying to convince your employer that your job is worthless.

Even If I like this tech, I still dont want to support the companies who make it. Yet to pay a cent to these companies, still using the credits given to me by my employer.

It's insane! We are so far beyond gpt-3.5 and gpt-4. If you're not approaching Claude Code and other agentic coding agents with an open mind with the goal of deriving as much value from them as possible, you are missing out on super powers.

On the flip side, anyone who believes you can create quality products with these tools without actually working hard is also deluded. My productivity is insane, what I can create in a long coding session is incredible, but I am working hard the whole time, reviewing outputs, devising GOOD integration/e2e tests to actually test the system, manually testing the whole time, keeping my eyes open for stereotypically bad model behaviors like creating fallbacks, deleting code to fulfill some objective.

It's actually downright a pain in the ass and a very unpleasant experience working in this way. I remember the sheer flow state I used to get into when doing deep programming where you are so immersed in managing the states and modeling the system. The current way of programming for me doesn't seem to provide that with the models. So there are aspects of how I have programmed my whole life that I dearly miss. Hours used to fly past me without me being the wiser due to flow. Now that's no longer the case most of the times.

I don't see how anything you're saying is a response to what I said.

You’re asking to see my company’s code base?

It’s not like with AI we’re making miraculous things you’ve never seen before. We’re shipping the same kinda stuff just much faster.

I don’t know what you’re looking for. Code is code it’s just more and more being written by AI.

I think it's analogous to writing and refining an outline for a paper. If you keep going, you eventually end up at an outline where you can concatenate what are basically sentences together to form paragraphs. This is sort of where you are now, if you spec well you'll get decent results.

I agree, I felt this a bit. The LLM can be a modeling peer in a way. But the phase where it goes to validate / implement is also key to my brain. I need to feel the details.

you have a point.. i'm still confused about how this will affect jobs, markets

in a way a personal project is different from a job duty, here you're exploring, less if no deadline.. at work if I feel the llm is doing everything and I don't really master, i risk my job and my skills rot.

That’d be challenging for him right now.

So now we're pro-slaughter and low-yield agriculture as long as we get to ride the keyboard eh?

>They say that using LLMs as advisors is already outdated, we should be doing fully agentic coding and just nudge the LLM etc. since we're losing out on 'productivity'.

As long as "they" are people that either profit from FOMO or bad developers that still don't produce better software than before, I'm ok ignoring the noise.

Same here. I had to do a lot of being in the loop with Python, but with rust - compiler gives Claude all the information it may need and then it figures things out without me.

Writing rust scares me, but I can read it just fine. I've come up with super masochistic linting rules that claude isn't allowed to change and that has improved things quite a bit.

I wish there was a mature framework for frontend that can be configured to be as strict as rust.

I agree that this will be the end result over time, maybe even faster than we expect. And as those speed pressures increase, AI will take over more and more of the development process.

That's something I find to be incredibly frustrating. I have to keep reminding it that we're not done, no matter how much I enforce that the lints must pass before we're done.

I see. That makes sense, but sometimes is makes code harder to read.

Maintaining a 'mental RAM Cache' is a powerful tool to understanding the system as a whole on a deep and intuitive level, even if you can only 'render' sections at a time. The bigger it is the more you can keep track of to be able to foresee interactions between distant pieces.

It shouldn't be your only source of a plan as you'd likely wind up dropping something, but figuring out how to jiggle things around before getting it 'on paper' is something I've found helpful.

It's almost like programming via markdown.

>Strange since, in practice, coding models have steadily improved without any backward movement every 3-4 months for 2 years now. It's as if there are rigorous methods of filtering and curation applied when building your training data.

It's as if what I wrote implies "all other things being equal", just like any technical claim.

All other things were not equal: the architectures were tweaked, the human data set is still not exhausted, and more money and energy was thrown into their performance since it's a pre-IPO game with huge VC stakes.

We've already seen a plateau non-the-less compared to the earlier release-over-release performance improvements. Even the "without any backward movement every 3-4 months for 2 years now" is hardly arguable. Many saw a backward movement with GPT 4.1 vs 4.0, and similar issues with 4.5, for example. Even if those are isolated, they're hardly the 2 to 3.5 to 4.0 gains.

And no, there are absolutely no "rigorous methods of filtering and curation" that can separate the avalance of AI slop from useful human output - at least not without diminishing the possible training data. The problem after all is not just to tell AI from human with automated curation (that's already impossible), the problem is to have enough valuable new human output, which becomes near a losing game as all aspects of "human" domains previously useful as training input (from code to papers) are tarnished by AI output.

Alternatively, another second order effect is can't sip latte anymore because you're orchestrating 8 bots do the work and you're back to 80%-100% time saturation.

Exactly this. Even if right now you, bottom level wage earning grunt, get to lighten your workload for a fleeting second, sit back and enjoy the latte it's only but a fleeting second until the capital class tighten the screws.

Most people will get laid off and made redundant and those who remain are going to have to run faster than ever to produce wealth for the capital owners.

Yea, I don’t think that will be the case. Spreadsheets simplified the work of junior finance people who did all the work by hand before. But more people work in finance now than before.

What do we want? Meaningless preventable toil! When do we want it? Now!

>But is it relevant if the code isn't for humans?

The implications to your statement seems to me that is: "you'll never have to directly care about it yourself, so why do you care about it?". Unless you were talking about the codebase in a user-application relationship which in this case feel free to ignore the rest of my post.

I don't believe that the code will become an implementation detail, ever. When all you do is ship an MVP to demonstrate what you're building then no one cares, before or after LLM assistance. But any codebase that lives more than a year and serves real users while generating revenue deserves to have engineers who knows what's happening beyond authoring markdown instructions to multiple agents.

Your claim seems to push us towards a territory where externalizing out thought processes to a third party is the best possible outcome for all parties, because the models will only get better and stay just as affordable.

I will respond to that by pointing out that, models that will ultimately be flawless in code generation will worth a fortune in terms of adding value, and any corporation that will win the arms race will be actually killing themselves by not raising the cost of access to their services by a metric ton. This is because there will be few LLM providers that actually worth it by then, and because oligopoly is a thing.

So no. I don't expect that we'll ever reach a point where the average person will be "speaking forth" software the same way they post on Reddit, without paying cancer treatment levels of money.

But even if it's actually affordable... Why would I ever want to use your app instead of just asking an LLM to make me one from scratch? No one seems to think about that.

i've been building agent tooling for a while and this is the question i keep coming back to. the actual failure mode isn't messy code, agents produce reasonably clean, well-typed output these days. it's that the code confidently solves a different problem than what you intended. i've had an agent refactor an auth flow that passed every test but silently dropped a token refresh check because it "simplified" the logic. clean code, good types, tests green, security hole. so for me "quality" has shifted from cyclomatic complexity and readability scores to "does the output behaviour match the specification across edge cases, including the ones i didn't enumerate." that's fundamentally an evaluation problem, not a linting problem.

This is where I think its going, it feels that in the end we will end up with an "llm" language, one that is more suited to how an llm works and less human.

You can’t drop anything as long as a programmer is expected to edit the source code directly. Good luck investigating a bug when the code is unclear semantically, or updating a piece correctly when you’re not really sure it’s the only instance.

There were always many mediocre engineers around, some of them even with fancy titles like "Senior," "Principal", and CTO.

We have always survived it, so probably we can also survive mediocre coders not reading the code the LLM generates for them because they are unable to see the problems that they were never able to see in their handwritten code.

Honestly it’s not that hard. I already coded less and less as part of my job as I get more senior and just didn’t have time, but I was still easy to do code reviews and fix bugs, sit down and whip out a thousand lines in a power session. Once you learn it doesn’t take much practice to maintain it. A lot of traditional coding is very inefficient. With AI it’s like we’re moving from combustion cars to EVs, the energy efficiency is night and day, for doing the same thing.

That said, the next generation may struggle, but they’ll find their way.

Personally I planned to allocate weekly challenges to stay sharp.

It’s going to be extremely difficult if PR and code reviews do not prune unnecessary functions. From what I’m experiencing now, there’s a lot of additional code that gets generated.

"That's the neat part—you don't." Eventually the workflow will be to use the LLM to interpret the LLM-generated codebase.

I don’t read or edit the code my claude code agent produces. That’s its job now. My job is to organize the process and get things done.

> if you know, and I know,

We don't know.

> and the guys at openai and anthropic know... not a big leap that the models will know too?

The models don't "know" anything. They just regurgitate what they are fed.

"Child abuse images found in AI training data"

https://www.axios.com/2023/12/20/ai-training-data-child-abus...

> many datasets are curated and labeled by humans

Including these ones: "AI industry insiders launch site to poison the data that feeds them"

https://www.theregister.com/2026/01/11/industry_insiders_see...

This 100%. We want MOAR!!!

> uses AI a lot

https://en.wikipedia.org/wiki/Model_collapse

> AI just means more output will be expected of you, and they'll keep pushing you to work as hard as you can.

That’s a bit too cynical for me. After all, yes, your boss is not paying you for sipping lattes, but for producing value for the company. If there is a tool that maximises your output, why wouldn’t he want you to use that to great efficiency?

Put differently, would a carpenter shop accept employees rejecting the power saw in favour of a hand saw to retain their artisanal capability?

>Or, there is just a lot more software written as the costs drop.

Yeah, no, that's wishful thinking. The companies will just opt for higher margins.

You or someone else might be expected. The rest will just be expected to be fired.

Right. I work in aerospace software, and I do not know if this option would ever be on the table. It certainly isn't now.

So I think this question needs to be asked in the context of particular projects, not as an industry-wide yes or no answer. Does your particular project still need humans involved at the code level? Even just for review? If so, then you probably ought to retain human-oriented software design and coding techniques. If not, then, whatever. Doesn't matter. Aim for whatever efficiency metric you like.

This is exactly what is happening from a levels of abstraction standpoint.

The difference being that compilers and related tools are deterministic, and we can manage the outputs using mathematical proof of correctness.

The LLM's driving this new abstraction layer are another beast entirely.

Do you mean, from your perspective, within 2 years humans won’t be able to bring anything of value to the equation in management and control ?

It’s also pretty close to Steve Jobs initial vision of computing in the future (https://stevejobsarchive.com/stories/objects-of-our-life, 1983) but my point is that whatever it is we call AI now became reality so much faster than anyone really saw coming. Even if the pace slows down, and it didn’t yet, things are improving so massively all the time that the world can’t keep up changing to accommodate.

What you described makes sense, and it's just one of the things to try. There are lots of other research directions: online learning, more efficient learning, better loss/reward functions, better world models from training on Youtube/VR simulations/robots acting in real world, better imitation learning, curriculum learning, etc. There will undoubtedly be architectural improvements, hardware improvements, longer context windows, insights from neuroscience, etc. There is still so much to research. And there are more AI researchers now than ever. Plus current AI models already make us (AI researchers) so much more productive. But even if absolutely no further progress is made in AI research, and foundational model development stops today, there's so much improvement to be made in the tooling around the models: agentic frameworks, external memory management, better online search, better user interactions, etc. The whole LLM field is barely 5 years old.

Maybe.

But it's also likely that these tools will produce mountains of unmaintainable code and people will get buried by the technical debt. It kind of strikes me as similar to the hubris of calling the Titanic "unsinkable." It's an untested claim with potentially disastrous consequences.

Oh I'm well aware of this. I admitted defeat in a way.. I can't compete. I'm just at loss, and unless LLM stall and break for some reason (ai bubble, enshittification..) I don't see a future for me in "software" in a few years.

> the cost-benefit analysis clearly favors letting these tools rip

Does it? I have yet to see any evidence that they are a net win in terms of productivity. It seems to just be a feeling that it's more efficient.

You can (and probably should) still do tests, but there's an entire class of errors you know can't happen, so you need far less tests, focusing only on business logic for the most part.

Static type checking is even faster than running the code. It doesn't catch everything, but if finding a type error in a fast test is good, then finding it before running any tests seems like it would be even better.

> If we make doing the right thing career limiting this all gets rather messy rather quickly.

This has already happened. The gold rush brogrammers have taken over.

Careers are over. Company loyalty is a relic. Now it's a matter of adapting quickly to earn enough to survive.

I have enough savings for a few years, so I might just move to a lower COL area, and wait it out. Hopefully after the initial chaos period things will improve.

I wonder about who "anybody can now output something acceptable" will hit most - engineers or software entrepreneurs.

Any implementation moat around rapid prototyping, and any fundraising moat around hiring a team of 10 to knock out your first few versions, seems gone now. Trying to sell MVP-tier software is real hard when a bunch of your potential customers will just think "thanks for the idea, I'll just make my own."

The crunch for engineers, on the other hand, seems like that even if engineers are needed to "orchestrate the agents" and manage everything, there could be a feature-velocity barrier for the software that you can still sell (either internally or externally). Changing stuff more rapidly can quickly hit a point of limited ROI if users can't adjust, or are slowed by constant tooling/workflow churn. So at some point (for the first time in many engineers' career, probably) you'll probably see product say "ok even though we built everything we want to test, we can't roll it all out at once!". But maybe what is learned from starting to roll those things out will necessitate more changes continually that will need some level of staffing still. Or maybe cheaper code just means ever-more-specialized workflows instead of pushing users to one-size-fits-all tooling.

In both of those cases the biggest challenge seems to be "how do you keep it from toppling down over time" which has been the biggest unsolved problem in consumer software development for decades. There's a prominent crowd right now saying "the agents will just manage it by continuing to hack on everything new until all the old stuff is stable too" but I'm not sure that's entirely realistic. Maybe the valuable engineering skills will be putting in the right guardrails to make sure that behavioral verification of the code is a tractable problem. Or maybe the agents will do that too. But right now, like you say, I haven't found particularly good results in conceptualizing better solutions from the current tools.

A/B happen at different abstractions levels. My abstraction level will be automated. My manager’s level will probably last another year or so.

I think this could work for some tasks but not for others.

We didn't invent formal languages to give commands to computers. We invented them as a tool for thinking and communicating things that are hard to express in natural language.

I doubt that we will stop thinking and I doubt that it will ever be efficient to specify tasks purely in terms of natural language.

One of my first jobs as a software engineer was for a bank (~30 years ago). This bank manager wasn't a man of many words. He just handed us an Excel sheet as a specification for what he wanted us to implement.

After a multi-decade career that spanned what is rapidly seeming like the golden age of software development, I have two emotions: first gratefulness; second a mixture of resignation, maudlin reflection, and bitterness that I am fighting hard to resist.

As someone who’s always wanted to “get home and code something on my own”, I do have a glimmer of hope that I wonder if others share. I’ve worked extensively with Claude and there’s no question I am now a high velocity “builder” and my broad experience has some value here. I am sad that I won’t be able to deeply look at all the code I am producing, but I am making sure the LLM and I structure things so that I could eventually dig in to modules if needed (unlikely to happen I suppose).

Anyway, my hope/question: if I embrace my new role as fast system builder and I am creative in producing systems that solve real problems “first”, is there a path to making that a career (I.e. 4 friends and I cranking out real production software that’s filling a real niche)? There must be some way for this to succeed —- I am not yet buying the “everything will be instantly copyable and so any solution is instantly commodity” argument. If that’s true, then there is no hope. I am still in shape, though, so going pro in pickleball is always an option, ha ha.

I hear you. And maybe you're right. Maybe I'm deluding myself, but: when I look at my skilled colleagues who vibecode, I can't understand how this is sustainable. They're smart people, but they've clearly turned off. They can't answer non-trivial questions about the details of the stuff they (vibe-)delivered without asking the LLM that wrote it. Whoever uses the code downstream aren't gonna stand (or pay!) for this long-term! And the skills of the (vibe-)authors will rapidly disappear.

Maybe I'm just as naive as those who said that photographs lack the soul of paintings. But I'm not 100% convinced we're done for yet, if what you're actually selling is thinking, reasoning and understanding.

Can you provide links to these videos?

"creativity involved in deciding what to build, with the choice informed by engineering experience (the project/value will not be obvious to everyone) will allow differentiation."

How? Anyone upon seeing your digital product can just prompt the same thing in no time. If you can prompt it, I can prompt it and so can a million other people.

Nobody whether an individual or business holds any uniqueness or advantage to themselves. All careers and skill sets are leveled and worthless. Implementation skills are worthless. Creativity is worthless.

The only valuable thing is data.

People are indeed not deterministic. But they are accountable. In the legal sense, of course, but more importantly, in an interpersonal sense.

Perhaps outsourcing is a good analogy. But in that case I'd call it outsourcing without accountability. LLMs feel more like an infinite chain of outsourcing.

Ofc people are non deterministic. But usually we expect machines to be. That’s why we trust them blindly and don’t check the calculations. We review people’s work all the time though. Here people will stop review machine LLM code as it’s kind of a source of truth like in other areas. That’s my point, reviewing code takes time and even more time when no human wrote it. It’s a dangerous path to stop reviews because of trust in the machine now that the machine is just kind of like humans, non deterministic.

For context, I just started using coding agents - codex CLI and Claude code in October. Once I saw that you had to be billed by use, I’m not using my own money for it when it’s for a company.

Two things changed - Codex CLI now lets you use it with your $20 a month subscription and I have never run into quota issues with it and my employer signed up for the enterprise vs of Claude and we each have an $800 a month allowances

My argument though is “why should I care about the code?” for the most part. If I were outsourcing a project or delegating it to a team lead, I would be asking high level architectural, security and scalability questions.

AI generated the code, AI maintains the code. I am concerned about abstractions and architecture.

You shouldn’t have to maintain or refactor “millions of lines of code”, if your code is well modularized with clean interfaces, making a change for $x7 may mean making a change for $x1…$x6. But you still should be working locally in one module at the time. You should do the same for the benefit of coders. Heck my little 5 week project has three independently deployable repos in a root folder. My root Agents file just has a summary of how all three relate via a clean interface.

In the project I am working on now, besides “does it meet the requirements”, I care about security, scalability, concurrency, user experience for the end user, user experience for the operations folks when they need to make config changes, and user experience for any developers who have to make changes long after I’m off this project. I haven’t looked at a single line of code - besides the CloudFormation templates. But I can answer any architectural question about any of it. The architecture and abstractions were designed by me and dictated to the agents

On this particular project, on the coding level, there is absolutely nothing that application code like this can do that could be insecure except hypothetically embed AWS credentials into the code. But it can’t do that either since it doesn’t have access to it [1].

In this case security posture comes from the architecture - S3 block public access, well scoped IAM roles, not running “in a VPC”. Things I am checking in the infrastructure as code and I was very specific about.

The user experience has to come from design and checking manually.

I mentioned earlier that my first stab it scaled poorly. This was caused by my design and I suspected it would beforehand. But building the first version was so fast because of AI tools, I felt no pain in going with my more architecturally complicated plan B and throwing the first version away. I wouldn’t have known that by looking at the code. The code was fine it was the underlying AWS service. I could only know that by throwing 100K documents at it instead of 1000.

I designed a concurrent locking mechanism that had a subtle flaw. Throwing the code into ChatGPT into thinking mode, it immediately found it. I might have been better off just to tell the coding agents “design a locking mechanism for $x” instead of detailing it.

Even maintainability was helped because I knew I or anyone else who touched it was probably going to be using an LLM. From the get go I threw the initial contract, the discovery sessions transcripts, the design diagrams, the review of the design diagrams, my project plan and breakdown into ChatGPT and told it to render a detailed markdown file of everything - that was the beginning of my AGENTS.md file.

I asked both Codex and Claude to log everything I was doing and my decisions into separate markdown files.

Any new developer could come into my repo, fire up Claude and it wouldn’t just know what was coded, it would have full context of the project from the initial contract through to the delivery

[1] code running on AWS never explicitly has to worry about AWS credentials , the SDKs can find the information by themselves by using the credentials of the IAM role attached to the EC2 instance, Lambda, Docker container, etc.

Even locally you should be getting temporary credentials that are assigned to environment variables that the SDK retrieved automatically.

Okay - and the person ultimately leading the team is still responsibility for it whether you are delegating to more junior developers or AI. You’re still reviewing someone else’s code based on your specs