|
Ah, weird, that's good to know. Well here's the code: import { env } from './env';
import { v4 as uuidv4 } from 'uuid';
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
import sharp from 'sharp';
async function retry<T>(fn: () => Promise<T>, maxAttempts: number): Promise<T> {
let attempt = 1;
while (true) {
try {
return await fn();
} catch (error) {
if (attempt >= maxAttempts) {
throw error;
}
const delayMs = Math.pow(2, attempt - 1) * 100;
await new Promise((resolve) => setTimeout(resolve, delayMs));
attempt++;
}
}
}
export async function processAndUploadImage(s3: S3Client, imageData: Uint8Array): Promise<string> {
let metadata;
try {
metadata = await sharp(imageData).metadata();
} catch {
throw new Error('Invalid image');
}
if (metadata.format !== 'png') {
throw new Error('Not a PNG image');
}
if (!metadata.width || !metadata.height || metadata.width !== metadata.height || metadata.width < 100) {
throw new Error('Image must have a 1:1 aspect ratio and resolution >= 100x100');
}
const resizedBuffer = await sharp(imageData).resize(100, 100).toBuffer();
const key = `${uuidv4()}.png`;
const command = new PutObjectCommand({
Bucket: env.IMAGE_BUCKET,
Key: key,
Body: resizedBuffer,
ContentType: 'image/png',
});
await retry(async () => {
await s3.send(command);
}, 100);
return key;
}
The prompting was the same as above, with the stipulations that it use TypeScript, import `env` from `./env`, and take the S3 client as the first function argument.You still need reference information of some sort in order to use any API for the first time. Knowing common Node.js AWS SDK functions offhand might not be unusual, but that's just one example. I often review source code of libraries before using them as well, which isn't in any way contradictory with involving AI in the development process. From my perspective, using AI is just like having a bunch of interns on speed at my beck and call 24/7 who don't mind being micromanaged. Maybe I'd prefer the end result of building the thing 100% solo if I had an infinite amount of time to do so, but given that time is scarce, vastly expanding the resources available to me in exchange for relinquishing some control over low-priority details is a fair trade. I'd rather deliver a better product with some quirks under the hood than let my (fast, but still human) coding speed be the bottleneck on what gets built. The AI may not write every last detail exactly the way I would, but neither do other humans. |
I’m not saying that I write flawless code, but I’m more for less feature and better code. I’ve battled code where people would add big libraries just to not write ten lines of code. And then can’t reason when a snippet fails because it’s unreliable code into unreliable code. And then after a few months, you got zombie code in the project. And the same thing implemented multiple times in a slightly different way each time. These are pitfalls that occur when you don’t have an holistic view of the project.
I’ve never found coding speed to be an issue. The only time when my coding is slow is when I’m rewriting some legacy code and pausing every two lines to decipher the intent with no documentation.
But I do use advanced editing tools. Coding speed is very much not a bottleneck in Emacs. And I had a somewhat similar config for Vim. Things like quick access to docs, quick navigation (thing like running a lint program and then navigating directly to each error), quick commit, quick blaming and time traveling through the code history,…